Hi Sasha, Personally I also think a new reverved label is a better solution. But I don't think we have provide very convienced answer of the initial question in this list: what is the benefit when deploying TC into MPLS network compared with current Ethernet/UDP solution.
BR Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 Jul 2010 18:06:24 +0300 > From: Alexander Vainshtein <[email protected]> > Subject: Re: [TICTOC] FW: 1588 over MPLS draft > To: Tal Mizrahi <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: > <a3c5df08d38b6049839a6f553b331c76d37fff5...@ilptmail02.ecitele.com> > Content-Type: text/plain; charset="us-ascii" > > Tal, > I think that we are in full agreement regarding a single-label GAL-only stack: > It allows the LSRs to modify PTP packets (as TC must do), but it > does not support forwarding (unicast and multicast). Hence it is useless. > IMO GAL/G-ACH are a clear dead end in this discussion. > > If you have been following this list, I've suggested allocating a > new reserved label which, at the top of the stack, would indicate > PTP packets. > IMHO this is the only method that would somehow accommodate TC > (which is a layer violation, of course) without completely breaking > MPLS data plane. > However, this approach did not gain support on the list. > > "PTP FEC" IMO is also a dead end. E.g., you would not be able such > popular recovery techniques as Facility FRR for this FEC, etc. > > At the same time, if TC support is not required, there is no need to > invent any special encapsulation of PTP over MPLS. All the rest of > the use cases can be easily accommodated with PTP/UDP/IP/MPLS > without inventing new wheels. > > My 2c, > Sasha > > From: Tal Mizrahi [mailto:[email protected]] > Sent: Monday, July 19, 2010 5:55 PM > To: Alexander Vainshtein > Cc: [email protected] > Subject: Re: [TICTOC] FW: 1588 over MPLS draft > > > Hi Sasha, all, > > > > A couple of comments: > > 1. Generally, regarding using GAL+ACH: according to RFC 5586: "LSRs > MUST NOT modify the G-ACh message, the ACH or the GAL towards the > targeted destination". However, a PTP capable LSR that functions as > a TC must modify the packet (including the correctionField and the > UDP checksum). This means that if an LSR functions as a TC, either > (a) the functionality in RFC 5586 must be enhanced to allow > modification, or (b) the LSR terminates all incoming PTP messages, > and then re-generates them, which may burden the control plane. > > 2. Sasha, regarding your option 1 below: if each packet has a label > stack with 1 label (GAL), it raises the question how to distinguish > between single-target and multi-target PTP packets. PTP calls for > both multicast frames (e.g.), and unicast (e.g. Delay_Req). > > > > That's not to say I am against using the GAL, but it needs some > further refinement. > > > > Tal. > > > > > > > > > > > > > > -----Original Message----- > > > > Yaakov and all, > > Please note that GAL and, by implication, the ACH header are only looked at by > > an LSTR if GAL happens to be the top label in the stack (either because it has > > been the top label in originally received packet, or because all the labels > > above it have been popped by this LSR). > > > > This leaves two options IMO: > > 1. You carry PTP directly across physical links using labeled packets that > > have a label stack of depth 1 containing GAL. > > In this case you can probably do want you want with the PTP packets' > > payload, (e.g., support TC), but you need some new mechanism for forwarding > > PTP packets along a multi-hop path. > > > > 2. You can carry PTP across any LSP using GAL at the bottom of the > label stack. > > In this case only the tail end of the LSP will be PTP-aware, i.e., TC will > > not be supported with this option. > > > > I suggest taking a look at http://datatracker.ietf.org/doc/draft- > ietf-mpls-tp-data-plane for details > > regarding MPLS (and MPLS-TP) data plane. > > > > Regards, > > Sasha > > > > -----Original Message----- > > From: tictoc-bounces at ietf.org [mailto:tictoc-bounces at ietf.org] > On Behalf Of Yaakov Stein > > Sent: Monday, July 19, 2010 12:06 PM > > To: Mikael Abrahamsson > > Cc: tictoc at ietf.org > > Subject: Re: [TICTOC] FW: 1588 over MPLS draft > > > > No. Not a new Ethertype - we are talking about MPLS NOT Ethernet. > > > > There is a protocol type (it's actually called a "channel type") > > in the Ach control word. See RFC 4385. > > Right now only a few are defined (raw BFD, IPv4, IPv6). > > > > > > Y(J)S > > > > -----Original Message----- > > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > > Sent: Monday, July 19, 2010 09:48 > > To: Yaakov Stein > > Cc: stbryant at cisco.com; tictoc at ietf.org > > Subject: Re: [TICTOC] FW: 1588 over MPLS draft > > > > On Sun, 18 Jul 2010, Yaakov Stein wrote: > > > > > 1) define a new protocol type (plenty of openings in THAT registry!) > > > > New protocol type on what level? Ethernet, so this would involve a new > > ethertype? > > > > If routers generally can look that far into the packet on the correct > > forwarding level (I doubt it though) then that would be the least > > intrusive, but having LSRs look for ethertype within MPLS labeled packets > > sounds kind of advanced to do that early in the receive path? > > > > Why not do it more like an MPLS L3 VPN terminated/routed by all > > involved&&aware routers, then it would signal special labels to its > > neighbours that would be local significance only? But now we're talking > > handling it like a tree and that would involve routing protocols as > > well... Basically this would be like multicast IP and could leverage all > > the multicast MPLS standards out there. > >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
