Shahram,
Lots of thanks for a prompt clarification.
But doesn't it mean that facility protection mode in FRR is effectively not
applicable to PTP LSPs?
Regards,
Sasha
> -----Original Message-----
> From: Shahram Davari [mailto:[email protected]]
> Sent: Tuesday, November 22, 2011 5:34 PM
> To: Alexander Vainshtein
> Cc: [email protected]; [email protected]; [email protected]
> Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
>
> Hi Sasha,
>
> Good question. We have mentioned in the draft that any label pushed such
> as FRR case must also be a PTP label. We have also provided extension to
> signaling so that labels are identified as being PTP label.
>
> Thanks
> Shahram
>
> -----Original Message-----
> From: Alexander Vainshtein [mailto:[email protected]]
> Sent: Tuesday, November 22, 2011 7:31 AM
> To: Shahram Davari
> Cc: [email protected]; [email protected]; [email protected]
> Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
>
> Shahram,
> I must admit that I have not been following discussions about PTP over
> MPLS, but I would like to clarify an issue that stems from reading your
> response to Stewart.
>
> If I interpret you correctly, you say that, instead of sending PTP in PWs you
> are going to send them in dedicated LSPs. The advantage is that the transit
> nodes may derive the need to examine PRP packets by just looking at the
> labels at the top of stack.
>
> The question is: what is supposed to happen if, for some reason, a transit
> node pushes yet another label on top of what has been originally allocated
> for a PTP-carrying LSP? FRR (in the facility mode when multiple LSPs would
> be tunneled in the same bypass) is one valid example IMO, but there could
> be more.
>
> Regards,
> Sasha
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Shahram Davari
> > Sent: Tuesday, November 22, 2011 5:21 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]
> > Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
> >
> > Hi Stewart,
> >
> > Thanks for your valuable input. Since these PTP LSPs are defined to only
> > carry IP or Ethernet encapsulated 1588 packets, the LSRs could easily parse
> > them without requiring to know the Payload type per PW label. In other
> > words if the LSP is a PTP LSP then the payload type is knwon and we don't
> > need to keep the payload type state per PW label. So I don't think we are
> > doing any layer violation.
> >
> > All an LSR has to do is to go to the BoS and check the first nibble after
> > BoS
> > label to find out whether payload is IPv4 (nibble = '0100'), IPv6 (nibble =
> > '0110'), OAM (nibble = '0001') or Ethernet (nibble = '0000') traffic. Only
> > IP
> and
> > Ethernet traffic needs further parsing to verify the 1588 packets. So really
> no
> > knowledge of the payload type per PW label is required and therefore I
> > think no layer violation.
> >
> >
> > Best Regards,
> > Shahram
> >
> >
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Stewart Bryant
> > Sent: Tuesday, November 22, 2011 1:13 AM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
> >
> >
> > Speaking as an individual here, I really have a hard time
> > understanding why it is necessary to have quite the
> > egregious layer violation that this draft uses.
> >
> > The idea of having an LSP type that is dedicated to
> > tracking the time of passage through the network
> > is a good idea. However MPLS is completely geared
> > to the concept that only the LSP endpoints know
> > how to resolve the payload type.
> >
> > The function that you require could be achieved
> > by including a shim that contains the
> > time compensation information and adjust the
> > payload on egress from the LSP. That would be
> > rather more consistent with the MPLS architecture.
> >
> > I have not seen a request for review by the MPLS
> > or PWE3 WGs and I would suggest that you request
> > that sooner rather than later since it is inevitable
> > that the draft will be sent there later in it's life, and
> > if they do not subscribe to your mode of operation
> > the draft is unlikely to progress.
> >
> > I would also suggest that you discuss the extent
> > of layer violation with your AD to make sure he is
> > confident that this draft will pass IESG review.
> >
> > - Stewart
> >
> >
> > _______________________________________________
> > TICTOC mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/tictoc
> >
> >
> > _______________________________________________
> > TICTOC mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/tictoc
>
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.
>
>
This e-mail message is intended for the recipient only and contains information
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this transmission in error, please inform us by e-mail, phone or fax,
and then delete the original and all copies thereof.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
