Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 11 Apr 2016 23:42:05 +0000

Authors,

For this draft, it would be useful to also discuss and understand a few
other things, such as:

I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL}
Entropy Label approach) been considered? It would save label stack
entries, and allow precise positioning. Has this been ruled out?
II. Definition of behavior for networks with hybrid support (some nodes
support ELC, some do not). Like, can/should EL;ELI be used if some nodes
in the path do not support it? This will be a very common case. Some
downstream NHs might support it and some don¹t.
III. Are there multi instance or flooding scope implications?
IV. As specified, there is no relationship between ELC and RLDC. Seems
there is. Do these need to be supported simultaneously? Say, a node does
not support ELC but advertises RLDC, what¹s that mean?
V. There are several operational considerations which are just unadressed.
Say, a new LC is inserted in a node, which does not support ELC, or
supports a RLD smaller than what¹s been advertised. Or...
VI. No security implications sounds quite optimistic :-)

Thanks,

‹ Carlos. 

-----Original Message-----
From: OSPF <[email-masked]> on behalf of "Acee Lindem (acee)"
<[email-masked]>
Date: Monday, April 11, 2016 at 2:38 PM
To: "[email-masked]" <[email-masked]>
Cc: OSPF WG List <[email-masked]>
Subject: [OSPF] Signaling Entropy Label Capability Using OSPF -
draft-ietf-ospf-mpls-elc-00

>Authors, 
>
>We will soon be progressing the OSPFv2 SR draft. What is your intent for
>this draft? It is missing:
>   
>    1. A figure with the RI encoding like other OSPF documents
>    2. Discussion as to precisely how the capability would be used by a
>router in an OSPF routing domain. For example, must a router remove the EL
>if the next-hop doesn¹t support it?
>    3. A discussion of backward compatibility for the new
>Router-Information LSA capability.
>
>Thanks,
>Acee
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Apr 2016 08:09:55 +0000

Hi Carlos,

Thanks for your comments. Please see my response inline.

> From: OSPF [mailto:[email-masked]] On Behalf Of Carlos Pignataro
> (cpignata)
> Sent: Tuesday, April 12, 2016 7:42 AM
> To: Acee Lindem (acee); [email-masked]
> Cc: OSPF WG List
> Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF -
> For this draft, it would be useful to also discuss and understand a few other
> things, such as:
> 
> I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL} Entropy
> Label approach) been considered? It would save label stack entries, and allow
> precise positioning. Has this been ruled out?

This document only describes how the ELC and RLSDC are advertised via OSPF. How these capabilities would be used are actually described in https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. As for an approach similar to FAT-PW, it may deserve a separate doc.

> II. Definition of behavior for networks with hybrid support (some nodes support
> ELC, some do not). Like, can/should EL;ELI be used if some nodes in the path do
> not support it? This will be a very common case. Some downstream NHs might
> support it and some don¹t.

See above.

> III. Are there multi instance or flooding scope implications?

As for multi-instances, the following text would be added into the next revision if the WG believe it's appropriate:

"To be compatible with RFC7770, ELC and RLSDC TLVs SHOULD continue to be advertised in the first instance, i.e., 0, of the Router Information LSA."

As for the flooding scope, it said in the doc that "The scope of the advertisement depends on the application but it is recommended that it SHOULD be AS-scoped."

> IV. As specified, there is no relationship between ELC and RLDC. Seems there is.
> Do these need to be supported simultaneously? Say, a node does not support
> ELC but advertises RLDC, what¹s that mean?

ELC and RLDC don't need to be supported simultaneously. For instance, a non-egress node doesn't need to support ELC but it's desirable to advertise the RLDC.

> Say, a new LC is inserted in a node, which does not support ELC, or supports a
> RLD smaller than what¹s been advertised. Or...

As for ELC, there is no difference from the current use of ELC as specified in RFC6790. In other words, a router should not advertise the ELC unless all of its LCs support ELC. In fact, this point has been raised before, the WG consensus was that there is no need to mention it explicitly in the doc, if I remembered it correctly. As for ELD, it said in the doc that "If a router has multiple linecards with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest one in the RLDC TLV. "

> VI. No security implications sounds quite optimistic :-)

Do you have any good suggestion on the security considerations?

Best regards,
Xiaohu

> < Carlos.
> >We will soon be progressing the OSPFv2 SR draft. What is your intent
> >for this draft? It is missing:
> >
> >router in an OSPF routing domain. For example, must a router remove the
> >EL if the next-hop doesn¹t support it?