Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

From: [email-masked]
Date: Mon, 01 Jun 2020 01:42:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

        Title           : Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF
        Authors         : Xiaohu Xu
                          Sriganesh Kini
                          Peter Psenak
                          Clarence Filsfils
                          Stephane Litkowski
                          Matthew Bocci
	Filename        : draft-ietf-ospf-mpls-elc-15.txt
	Pages           : 9
	Date            : 2020-06-01

Abstract:
   Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
   balance traffic flows using Entropy Labels (EL).  An ingress Label
   Switching Router (LSR) cannot insert ELs for packets going into a
   given Label Switched Path (LSP) unless an egress LSR has indicated
   via signaling that it has the capability to process ELs, referred to
   as the Entropy Label Capability (ELC), on that LSP.  In addition, it
   would be useful for ingress LSRs to know each LSR's capability for
   reading the maximum label stack depth and performing EL-based load-
   balancing, referred to as Entropy Readable Label Depth (ERLD).  This
   document defines a mechanism to signal these two capabilities using
   OSPFv2 and OSPFv3 and BGP-LS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 1 Jun 2020 10:49:28 +0000

Hi Authors,

I see the following words in the introduction.
"   Recently, mechanisms have been defined to signal labels via link-
   state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "

It's not clear to me what the " mechanisms " are. Could you please add some reference or text on this?

Thanks,
Tianran

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 1, 2020 4:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Mon, 1 Jun 2020 12:55:38 +0200

Tianran,

> It's not clear to me what the " mechanisms " are. Could you please add some reference or text on this?

the reference is there - RFC8667.

thanks,
Peter

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 2 Jun 2020 06:14:13 +0000

Hi Peter,

I do not understand how RFC8667 relates to ELC signaling.
RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism to signal the ELC using IS-IS."

On the other hand, RFC 8667 is the extension for segment routing. 
Is this draft only for segment routing, or be generic?

Another thing I am not clear is the difference between "multi-area" and "multi-domain" here after:
   "Even though ELC is a property of the node, in some cases it is
   advantageous to associate and advertise the ELC with a prefix.  In a
   multi-area network, routers may not know the identity of the prefix
   originator in a remote area, or may not know the capabilities of such
   originator.  Similarly, in a multi-domain network, the identity of
   the prefix originator and its capabilities may not be known to the
   ingress LSR."

Tianran

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Monday, June 1, 2020 6:56 PM
To: Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 2 Jun 2020 10:10:26 +0200

Tianran,

> I do not understand how RFC8667 relates to ELC signaling.

RFC 8667 - IS-IS Extensions for Segment Routing

> RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism to signal the ELC using IS-IS."

yes, and as labels are now signaled by IGPs, we provide a method to 
signal ELC/ERLD by IGPs as well.

> Is this draft only for segment routing, or be generic?

the requirement document is RFC8662, which is SR specific.

>     the prefix originator and its capabilities may not be known to the

multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.

thanks,
Peter

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 2 Jun 2020 08:25:21 +0000

Peter,

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, June 2, 2020 4:10 PM
To: Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

> RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism to signal the ELC using IS-IS."

yes, and as labels are now signaled by IGPs, we provide a method to signal ELC/ERLD by IGPs as well.

ZTR> RFC8667 signals different SID. But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy label is also signaled by IGP?

ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is draft-ietf-ospf-mpls-elc SR specific?

Thanks,
Tianran

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 2 Jun 2020 10:31:04 +0200

Tianran,

On 02/06/2020 10:25, Tianran Zhou wrote:
> ZTR> RFC8667 signals different SID. 

no, RFC8667 is ISIS extension for SR MPLS.

> But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy label is also signaled by IGP?

no, entropy label is not signaled AFAIK.

> ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is draft-ietf-ospf-mpls-elc SR specific?

SR was a primary motivation.

regards,
Peter

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 2 Jun 2020 08:39:16 +0000

I think I understand your clarification.
Let me conclude, so your logic is:
We can use IGP to signal labels, though entropy label is not included. So we can use IGP to signal entropy label capability.

If so, this logic is not straight forward to me.

Tianran

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, June 2, 2020 4:31 PM
To: Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

regards,
Peter

---

From: wangyali <[email-masked]>
Date: Wed, 3 Jun 2020 11:35:32 +0000

Hi authors,

After reading this draft, I am not clear with following points.

First,  as said " Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix.", what are "some cases" in which it is advantageous to associate and advertise the ELC with a prefix? And ELC is a property of the node, why don't extend the OSPF RI Opaque LSA to carry ELC?

Second, as said " If a router has multiple interfaces, the router MUST NOT announce ELC unless all of its interfaces are capable of processing ELs. ", why do not consider ELC advertisement in link granularity? 

Third, as said " If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF.", what is the "every local host prefix"?

Last one, as defined that ERLD is advertised in a Node MSD TLV, why the ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored."

Best regards,
Yali

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 1, 2020 4:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Abstract:

---

From: Peter Psenak <[email-masked]>
Date: Wed, 3 Jun 2020 13:43:50 +0200

Yali,

> First,  as said " Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix.", what are "some cases" in which it is advantageous t…

this has been discussed on the WG alias endlessly, please go over the 
archives.

> Second, as said " If a router has multiple interfaces, the router MUST NOT announce ELC unless all of its interfaces are capable of processing ELs. ", why do not consider ELC advertisement in link…

and how do you as a remote router know over which interface, or better 
line card, the traffic that you are sending going to arrive on a remote 
node? Does not make much sense.

> Third, as said " If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF.", what is the "every local host prefix"?

it's a locally generated host prefix.

> Last one, as defined that ERLD is advertised in a Node MSD TLV, why the ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When the ERLD-MSD type is received in the OSPFv2 or…

yes, what's wrong with that statement?

regards,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Jun 2020 13:45:31 +0000

Speaking as WG chair:

It seems were getting a number of questions and comments on these ELC signaling documents as they go to the RFC Queue. I'd like to encourage review and discussion of LSR documents earlier in the WG process. One way to facilitate this would be for the authors to solicit review and discussion on the LSR list. This can be done at any time but should be done when documents are refreshed. 

Thanks,
Acee

On 6/3/20, 7:36 AM, "Lsr on behalf of wangyali" <[email-masked] on behalf of [email-masked]> wrote:

    Hi authors,

    Best regards,
    Yali

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] 
    Sent: Monday, June 1, 2020 4:42 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

    Abstract:

---

From: wangyali <[email-masked]>
Date: Wed, 3 Jun 2020 13:51:23 +0000

Hi Peter,

Thanks for your reply. please see inline <Yali>.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, June 3, 2020 7:44 PM
To: wangyali <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,

> First,  as said " Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix.", what are "some cases" in which it is advantageous t…

this has been discussed on the WG alias endlessly, please go over the archives.
<Yali> Thanks. I think I lost some emails. I will search them. While I suggest give an illustration or some examples about the "some cases" in the draft. Please take it into account. 

> Second, as said " If a router has multiple interfaces, the router MUST NOT announce ELC unless all of its interfaces are capable of processing ELs. ", why do not consider ELC advertisement in link…

and how do you as a remote router know over which interface, or better line card, the traffic that you are sending going to arrive on a remote node? Does not make much sense.
<Yali> So can we say that ELC advertisement in node granularity is expressed by host prefix attributes advertisement? 

yes, what's wrong with that statement?
<Yali> I think it will not happen. Why is it necessary to specify this case? 

regards,
Peter

---

From: wangyali <[email-masked]>
Date: Wed, 3 Jun 2020 14:01:01 +0000

Hi Acee,

Thanks for your kind suggestion. 

Best regards,
Yali

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Wednesday, June 3, 2020 9:46 PM
To: wangyali <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Speaking as WG chair:

Thanks,
Acee

    Hi authors,

    Best regards,
    Yali

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] 
    Sent: Monday, June 1, 2020 4:42 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

    Abstract:

---

From: Peter Psenak <[email-masked]>
Date: Wed, 3 Jun 2020 17:04:22 +0200

Yali,

> <Yali> Thanks. I think I lost some emails. I will search them. While I suggest give an illustration or some examples about the "some cases" in the draft. Please take it into account.

I will not make any changes to the draft at this point. The draft is in 
the RFC queue, too late to make changes.

> <Yali> So can we say that ELC advertisement in node granularity is expressed by host prefix attributes advertisement?

yes, pretty much that is the idea.

> <Yali> I think it will not happen. Why is it necessary to specify this case?

If someone sends this as link MSD, we need to say how to deal with it as 
in general MSDs can be send as node or link attributes.

regards,
Peter

---

From: wangyali <[email-masked]>
Date: Thu, 4 Jun 2020 03:09:00 +0000

Hi Peter,

Please see inline <Yali2>. Thanks.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, June 3, 2020 11:04 PM
To: wangyali <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,

> <Yali> Thanks. I think I lost some emails. I will search them. While I suggest give an illustration or some examples about the "some cases" in the draft. Please take it into account.

I will not make any changes to the draft at this point. The draft is in the RFC queue, too late to make changes.
<Yali2> Thanks. I am going over the mail archive to find these cases. I am very willing to learn and understand key points of this draft. 

yes, pretty much that is the idea.
<Yali2> I am appreciate if you could summary the reason.

> <Yali> I think it will not happen. Why is it necessary to specify this case?

If someone sends this as link MSD, we need to say how to deal with it as in general MSDs can be send as node or link attributes.
<Yali2> OK. I think I got your point and I read sec.4 again. So ERLD advertisement in a Node MSD TLV [RFC8476] is an optional method but not mandatory, is it right?

regards,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 4 Jun 2020 10:52:32 +0200

Yali,

please see inline:

> <Yali2> I am appreciate if you could summary the reason.

the reason is to support inter-area and inter-domain cases, where node 
attributes are not visible, but prefix attributes are.

> <Yali2> OK. I think I got your point and I read sec.4 again. So ERLD advertisement in a Node MSD TLV [RFC8476] is an optional method but not mandatory, is it right?

correct.

thanks,
Peter

---

From: wangyali <[email-masked]>
Date: Fri, 5 Jun 2020 04:25:58 +0000

Hi Peter,

Thanks. Please see inline <Yali3>.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, June 4, 2020 4:53 PM
To: wangyali <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,

please see inline:

> <Yali2> I am appreciate if you could summary the reason.

the reason is to support inter-area and inter-domain cases, where node attributes are not visible, but prefix attributes are.
<Yali3>Appreciate. While AFAIK, OSPFv2 type-11 RI Opaque LSAs and OSPFv3 S1S2-01 RI Opaque LSAs are flooded  throughout the Autonomous System. For the Inter-Area flooding scope, I am not clear what is the difference?

correct.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 5 Jun 2020 09:55:47 +0200

Yali,

> <Yali3>Appreciate. While AFAIK, OSPFv2 type-11 RI Opaque LSAs and OSPFv3 S1S2-01 RI Opaque LSAs are flooded  throughout the Autonomous System. For the Inter-Area flooding scope, I am not clear what…

it is certainly not flooded across multiple IGP domains.

thanks,
Peter

---

From: wangyali <[email-masked]>
Date: Fri, 5 Jun 2020 08:52:13 +0000

Hi Peter,
Please see inline <Yali4>.
Thanks,
Yali

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Friday, June 5, 2020 3:56 PM
To: wangyali <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,

it is certainly not flooded across multiple IGP domains.
<Yali4> I think it's helpful for a case that advertisement by using IGP alone. Is it right?

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Jun 2020 11:27:56 +0000

Hi Yali, 

On 6/5/20, 4:52 AM, "Lsr on behalf of wangyali" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Peter,

    -----Original Message-----
    From: Peter Psenak [mailto:[email-masked]] 
    Sent: Friday, June 5, 2020 3:56 PM
    To: wangyali <[email-masked]>; [email-masked]
    Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

    Yali,

Advertisement outside the OSPF routing domain is dictated by local redistribution policy (aka, import/export policy) and is certainly beyond the scope of this specification. Whether or not  such advertisement is helpful is dependent on the use case but I'm sure there would be situations where it would be helpful.

Thanks,
Acee

    thanks,
    Peter

---

From: wangyali <[email-masked]>
Date: Sun, 7 Jun 2020 05:33:25 +0000

Hi Acee,

Thanks for your directions. 

Best Regards,
Yali

-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]] 
发送时间: 2020年6月5日 19:28
收件人: wangyali <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
主题: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Hi Yali, 

    Hi Peter,

    -----Original Message-----
    From: Peter Psenak [mailto:[email-masked]] 
    Sent: Friday, June 5, 2020 3:56 PM
    To: wangyali <[email-masked]>; [email-masked]
    Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

    Yali,

Thanks,
Acee

    thanks,
    Peter