Sasha
1) Why do we need to define an MPLS (or MPLS-TP) encap ?
As many have said TC (or BC) is one reason.
[[Sasha]] TC is the reason, BC, IMO, is not.
<YJS> IMO it is. There are many reasons to shun TCs. They are a cute trick,
but the layer violation can mean trouble in many cases. BCs avoid the problem,
at the cost of
1) more complex implementation at mid points, and 2) phase error accumulation.
<snip>
Perhaps a better reason for now is QoS. I really want to easily recognize a
timing flow to give it EF service.
[[Sasha]] QoS is IMO not an issue. It exists over IP as well as over MPLS.
Yes, QoS exists, but we need to know what QoS to give to what.
Shahram's suggestion is to use specific labels. That is OK, but may be
troublesome to implement.
About a year ago I put together a list of 9 ways to send 1588 over MPLS, and
the first one
was UDP/IP/MPLS. In the preliminary discussions most people thought that this
was the route
to use if we can not standardize something better (it can be done NOW). Just
set up a minimum delay
LSP for the timing flow, and the problem is solved. Or is it ?
The first problem is scaling. Remember the early days of PWE ? The original
suggestion was
PW = LSP, but then Luca convinced us that this doesn't scale. You can't expect
all the P routers
to know about all these labels. and for timing we may need thousands of unicast
flows going through the core
(of course multicasting is another solution).
That is why my following methods relied on a universal marking.
[[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect and
modify the packet,
you need a RA label or, rather, its analog - let's call it the PTP Alert label,
or PTPA for (not so) short.
This would be a new reserved label (and yes, some are still left) with the
following rules:
- just as the RA label, it can be anywhere in the stack except at the bottom
- An LSR that observes this label (because it was at the top of the stack or
because it has popped all the labels
above it) will do the following:
* Check the payload of the MPLS packet for being a PTP packet in one of the
existing encapsulations
(my personal preference is PTP over UDP/IP, but it is not that relevant)
* If the check succeeds and the LSR is a TC, update the correction field in
this packet
* Forward this packet as indicated by the label immediately below the PTPA.
If this means sending
a labeled packet, add PTPA at the top of the resulting label stack (again,
same treatment as for the RA).
The forwarding rule is applied regardless of the results of check for
carrying PTP.
The only differences with RA is that passing the PTPA-labeled packet to a
software module is not required
(and probably should be avoided).
<YJS> YES ! This is my method number 3. A new reserved label. Of course we
need to convince the MPLS
WG to give us one (there aren't that many ...)
It would be also pretty easy to check if there any malicious LSRs on your LSP
that do not recognize PTPA: just use ICMP-Ping in this LSP with and without
added PTPA on top... if it does not work with PTPA but works without it, there
is an LSR that treats PTPA as an unknown label and discards the packet...
<YJS> YES. We are thinking along the same lines.
Of course an alternative would be a well-known, or at least network-wide CoS
bit combination (alternative 2).
Or a PW with certain marking in the control word (alternative 4).
Or using the GAL GAch.
[[Sasha]] Does this make sense?
<YJS> yes, IMO. Shahram's approach makes sense if there are only a small
number of timing flows.
Universal markings makes sense if there are many.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
