Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

From: Mach Chen <[email-masked]>
Date: Fri, 13 Nov 2015 08:12:20 +0000

Hi Sasha,

Thanks for your comments and the suggestions!

Please see my replies inline...
> 
> From: Pals [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: Thursday, November 12, 2015 10:28 PM
> To: Stewart Bryant; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> 
> Stewart and all,
> I have a couple of (possibly, naïve) concerns regarding this draft.
> Clarifying these concerns would help me to form an opinion regarding its
> support in the WG LC.
> 
> 1. The draft mentions (in many places) "a single  bidirectional co-routed LSP
> or two LSPs that share the same route" and uses this construct as if its two
> comprising components are equivalent. I do not think this is correct because:
> a. A co-routed bidirectional LSP is defined in RFC 5654, and its most important
> characteristic is that the two unidirectional LSPs comprising it, in addition to
> crossing the same sequence of nodes and links, have common life span (quoting
> from 5456: "Both directions are setup, monitored and protected as a single
> entity"). So it makes sense for one of the PEs terminating a PW and selecting
> one direction of a co-routed bi-directional LSP to request that the PE containing
> the remote PW endpoint  uses the reverse direction of such an LSP b. To the
> best of my understanding "two LSPs that share the same route" but do not
> form two directions of a co-routed bidirectional LSP by definition cannot have
> common life span. E.g., they could originally share the same route but,
> following some network event, could follow diverse routes (e.g., if each of them
> uses RSVP-TE-like FRR in link-and-node protection mode). So using such a pair of

Yes, this is true. 

> LSPs for carrying a PW that is supposed to be carried across the same set of
> links in two directions cannot be guaranteed and seems inconsistent with the
> perceived purpose of the draft.

Since quite a lot of networks support only unidirectional LSPs, binding to two LSPs that share the same route is mainly for the case where co-routed bidirectional LSP is supported in the network.

> c. One possible way to resolve this issue would be to restrict the draft to just
> co-routed bidirectional LSPs, but I am not sure whether this matches the
> authors' intention.

The intention/logical is that the co-routed bidirectional LSP should be used if there have, otherwise two unidirectional LSPs with the same route can be used.

How about we add some text to make this clear and give some cautions to the case of "two unidirectional LSPs with the same route"?

> 2.  The draft seems to use MPLS-TP Node Identifiers as defined in RFC 6370. I
> have two concerns in this regard:
> a. RFC 6923 defines an alternative format of MPLS-TP identifiers based on
> ITU-T.  But the draft neither supports this alternative format nor explicitly
> states that it must be supported 

There is no intention to support the ITU-T based identifier. Do you suggest to make this explicitly?

>b. 6370 explicitly states that "the Node_ID
> does not  need to have any association with the IPv4 address space used in
> the  operator's IGP or EGP". At the same time in order to set up a tLDP
> adjacency with the MPLS-TP node containing the remote endpoint of a PW, the
> active PE (as defined in the draft) must use one of its some routable IP
> addresses. To me that means that in order to use the draft each MPLS-TP node
> MUST support 1:1 mapping between routable IP addresses used as the
> endpoints of tLDP adjacencies and MPLS-TP Node Identifiers for all the nodes in
> the domain. A trivial way to achieve that would be using loopback IP addresses
> of these nodes as their MPLS-TP node identifiers, but the draft does not
> mention this possibility (or any alternative).

How about add the following text to Section 2.1.1:
"According to Section 5.3 of [RFC6370], the Source Node ID is mapped to the "Extended Tunnel ID" [RFC3209], and the Destination Node ID is mapped to the "Tunnel endpoint address". As defined in Section 4.6.1 and 4.6.2 of [RFC3209], both the "Tunnel endpoint address" and "Extended tunnel address" are IPv4/IPv6 addresses of the ingress and egress nodes. That means the Source/Destination Node IDs are routable addresses (e.g., TE router ID)."

> 
> Hopefully these notes will be useful.
Yes, they are very useful!

Thanks,
Mach

> 
> My 2c,
> Sasha
> 
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   [email-masked]
> 
> -----Original Message-----
> From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Thursday, November 12, 2015 2:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> 
> This email is to do two things:
> 
> 1) To start the PALS WG call on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> The document can be found at
> 
> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp/
> 
> This last call will run until 25th November 2015.
> 
> Please respond to this email with substantive comments on the document. It is
> also useful if those that have read the text and believe that it is ready to send
> to the IESG confirm that.
> 
> 2) To verify that all IPR known to the WG has been declared. Please declare this
> regardless of whether you are an author or not.
> 
> However I specifically need to have a response from the first three authors in
> the author list on this.
> 
> Thanks
> 
> Stewart
> 
> 
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals

---

From: Mach Chen <[email-masked]>
Date: Fri, 13 Nov 2015 08:21:38 +0000

s/co-routed bidirectional LSP is supported in the network/ co-routed bidirectional LSP is not supported in the network.

Best regards,
Mach

> From: Mach Chen [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 4:12 PM
> To: Alexander Vainshtein; Stewart Bryant; [email-masked];
> Subject: RE: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> 
> Hi Sasha,
> 
> > Subject: Re: [Pals] PALS WGLC on
> > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> >
> > Stewart and all,
> > Clarifying these concerns would help me to form an opinion regarding
> > its support in the WG LC.
> >
> > 1. The draft mentions (in many places) "a single  bidirectional
> > co-routed LSP or two LSPs that share the same route" and uses this
> > construct as if its two comprising components are equivalent. I do not think
> this is correct because:
> > a. A co-routed bidirectional LSP is defined in RFC 5654, and its most
> > important characteristic is that the two unidirectional LSPs
> > comprising it, in addition to crossing the same sequence of nodes and
> > links, have common life span (quoting from 5456: "Both directions are
> > setup, monitored and protected as a single entity"). So it makes sense
> > for one of the PEs terminating a PW and selecting one direction of a
> > co-routed bi-directional LSP to request that the PE containing the
> > remote PW endpoint  uses the reverse direction of such an LSP b. To
> > the best of my understanding "two LSPs that share the same route" but
> > do not form two directions of a co-routed bidirectional LSP by
> > definition cannot have common life span. E.g., they could originally
> > share the same route but, following some network event, could follow
> > diverse routes (e.g., if each of them uses RSVP-TE-like FRR in
> > link-and-node protection mode). So using such a pair of
> 
> Yes, this is true.
> 
> > LSPs for carrying a PW that is supposed to be carried across the same
> > set of links in two directions cannot be guaranteed and seems
> > inconsistent with the perceived purpose of the draft.
> 
> Since quite a lot of networks support only unidirectional LSPs, binding to two
> LSPs that share the same route is mainly for the case where co-routed
> bidirectional LSP is supported in the network.
> 
> > c. One possible way to resolve this issue would be to restrict the
> > draft to just co-routed bidirectional LSPs, but I am not sure whether
> > this matches the authors' intention.
> 
> The intention/logical is that the co-routed bidirectional LSP should be used if
> there have, otherwise two unidirectional LSPs with the same route can be
> used.
> 
> How about we add some text to make this clear and give some cautions to the
> case of "two unidirectional LSPs with the same route"?
> 
> > 2.  The draft seems to use MPLS-TP Node Identifiers as defined in RFC
> > 6370. I have two concerns in this regard:
> > a. RFC 6923 defines an alternative format of MPLS-TP identifiers based
> > on ITU-T.  But the draft neither supports this alternative format nor
> > explicitly states that it must be supported
> 
> >b. 6370 explicitly states that "the Node_ID  does not  need to have any
> >association with the IPv4 address space used in  the  operator's IGP or
> >EGP". At the same time in order to set up a tLDP  adjacency with the
> >MPLS-TP node containing the remote endpoint of a PW, the  active PE (as
> >defined in the draft) must use one of its some routable IP  addresses.
> >To me that means that in order to use the draft each MPLS-TP node  MUST
> >support 1:1 mapping between routable IP addresses used as the
> >endpoints of tLDP adjacencies and MPLS-TP Node Identifiers for all the
> >nodes in  the domain. A trivial way to achieve that would be using
> >loopback IP addresses  of these nodes as their MPLS-TP node
> >identifiers, but the draft does not  mention this possibility (or any
> alternative).
> 
> "According to Section 5.3 of [RFC6370], the Source Node ID is mapped to the
> "Extended Tunnel ID" [RFC3209], and the Destination Node ID is mapped to the
> "Tunnel endpoint address". As defined in Section 4.6.1 and 4.6.2 of [RFC3209],
> both the "Tunnel endpoint address" and "Extended tunnel address" are
> IPv4/IPv6 addresses of the ingress and egress nodes. That means the
> Source/Destination Node IDs are routable addresses (e.g., TE router ID)."
> 
> >
> > To: [email-masked];
> > 1) To start the PALS WG call on
> > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
> > Please respond to this email with substantive comments on the
> > document. It is also useful if those that have read the text and
> > believe that it is ready to send to the IESG confirm that.
> >
> > 2) To verify that all IPR known to the WG has been declared. Please
> > declare this regardless of whether you are an author or not.
> >
> > However I specifically need to have a response from the first three
> > authors in the author list on this.
> >
> > Thanks
> >
> > Stewart
> >
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 14 Nov 2015 19:44:55 +0000

Mach hi!
Lots of thanks for a prompt response.

Please see inline below.

Regards,
Sasha

________________________________________
From: Pals <[email-masked]> on behalf of Mach Chen <[email-masked]>
Sent: Friday, November 13, 2015 10:21 AM
To: Mach Chen; Alexander Vainshtein; Stewart Bryant; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

Best regards,
Mach

> case of "two unidirectional LSPs with the same route"?
[[Sasha]] This would be good enough IMHO.
> There is no intention to support the ITU-T based identifier. Do you suggest to
> make this explicitly?[[Sasha]] Yes, with an Informative reference to 6923. I assume that Informative would be sufficient for something that is not going to be implemented[😳].
>
[[Sasha]] I am not sure that the reference to 3209 is relevant since MPLS-TP tunnels (including co-routed bidirectional ones) could be set up by manual configuration, and, to the best of my understanding, this would not prevent the draft to work properly. Just saying that, in spite of flexibility provided by 6370,  Node IDs used in the new sub-TLVs MUST be routable IP addresses of the the containing nodes. Since LDP advertises to each end of the session all IP addresses of the other end in the Address message this would provide the required mapping IMHO. Does this make sense to you?

---

From: Mach Chen <[email-masked]>
Date: Mon, 16 Nov 2015 01:50:07 +0000

Hi Sasha,

Thanks for your suggestions!

Please see my response inline…

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Sunday, November 15, 2015 3:45 AM
To: Mach Chen
Cc: Stewart Bryant; [email-masked]; [email-masked]
Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

Mach hi!

Please see inline below.

Regards,
Sasha

________________________________________
From: Pals <[email-masked]<mailto:[email-masked]>> on behalf of Mach Chen <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 13, 2015 10:21 AM
To: Mach Chen; Alexander Vainshtein; Stewart Bryant; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

Best regards,
Mach

> To: Alexander Vainshtein; Stewart Bryant; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> > To: Stewart Bryant; [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>

[Mach] Great!

> make this explicitly?[[Sasha]] Yes, with an Informative reference to 6923. I assume that Informative would be sufficient for something that is not going to be implemented[😳].

[Mach] OK.

[Mach] Yes, it makes sense to me!

We will update the draft accordingly with other WG last call comments!

Thanks,
Mach
> > Email:   [email-masked]<mailto:[email-masked]>
> >
> > To: [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
Pals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pals

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 16 Nov 2015 05:40:09 +0000

Mach,

Lots of thanks for a prompt and very positive response.

I believe we are in sync now.

Stewart and the WG,

I support requesting publication of the draft (with the changes reflecting the outcome of this discussion).

Regards,

Sasha

________________________________
From: Mach Chen <[email-masked]>
Sent: Monday, November 16, 2015 3:50 AM
To: Alexander Vainshtein
Cc: Stewart Bryant; [email-masked]; [email-masked]
Subject: RE: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

Hi Sasha,

Mach hi!

Please see inline below.

Regards,

Sasha

Best regards,
Mach

[Mach] Great!

> make this explicitly?[[Sasha]] Yes, with an Informative reference to 6923. I assume that Informative would be sufficient for something that is not going to be implemented[??].

[Mach] OK.

Thanks,

Mach

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 16 Nov 2015 14:56:00 +0100

All,

> case of "two unidirectional LSPs with the
same route"?

[[Sasha]] This
would be good enough IMHO.

[Mach] Great!

The advantage of co-routed bidirectional LSPs is that the sink MEP

is co-located with the source MEP and they have a connection
required

to return OAM information (packet loss, delay, signal fail).

This is a requirement for MPLS-TP.

With two uni-directional LSPs this is not obvious, and in case they
are

used should be noted explicitly.

> make this explicitly?[[Sasha]] Yes,
with an Informative reference to 6923. I
assume that Informative would be sufficient
for something that is not going to be
implemented.

[Mach] OK.

The number of bits/bytes used for the ID is the same, it is only

the format of the ID that is different.

Why make an explicit reference?

Best regards, Huub.

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 16 Nov 2015 14:38:07 +0000

Huub hi!

You have written (with regard to IETF vs. ITU-T Global ID formats):
The number of bits/bytes used for the ID is the same, it is only the format of the ID that is different.
Why make an explicit reference?
I may be missing of misunderstanding something but:

·         As per RFC 6923 ITU-T Global ID is provided by concatenating 2-character Country Code with the ITU-T-assigned alphanumeric string of up to 6 characters. So the total length of the Global_ID is 8 bytes.

·         As per RFC 6370 the IETF Global ID is 4 bytes.
This does not look like the same number of bits/bytes to me.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Pals [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Monday, November 16, 2015 3:56 PM
To: [email-masked]
Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

All,

[Mach] Great!

The advantage of co-routed bidirectional LSPs is that the sink MEP
is co-located with the source MEP and they have a connection required
to return OAM information (packet loss, delay, signal fail).
This is a requirement for MPLS-TP.

With two uni-directional LSPs this is not obvious, and in case they are
used should be noted explicitly.

> make this explicitly?[[Sasha]] Yes, with an Informative reference to 6923. I assume that Informative would be sufficient for something that is not going to be implemented[��].

[Mach] OK.

Best regards, Huub.

--

              请记住，你是独一无二的，就像其他每一个人一样