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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Apr 2016 17:38:41 +0000

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

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Apr 2016 07:41:36 +0000

Hi Acee,

Thanks for your comments. Please see my response in line.

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2016 1:39 AM
> To: [email-masked]
> Cc: OSPF WG List
> Subject: 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:
> 

Will add two figures for ELC TLV and RLSDC TLV respectively.

>     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?

This document only describes how the ELC and RLSDC are advertised via OSPF. As for how these capabilities would be used are actually described in https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. By the way, a router doesn't need to remove the EL if the next-hop doesn't support it. The only requirement on using EL is: An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it can process ELs on that tunnel.

>     3. A discussion of backward compatibility for the new Router-Information
> LSA capability.

Is it enough to add the following text:

"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."

Best regards,
Xiaohu

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2016 12:41:17 +0000

Hi Tiger, 

>Will add two figures for ELC TLV and RLSDC TLV respectively.

Can you come up with a better name than RLSDC? It appears this would
obviate the need for the recent MSD proposal but that is a much better
name. 

>>router in
>This document only describes how the ELC and RLSDC are advertised via
>OSPF. As for how these capabilities would be used are actually described
>in https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. By
>the way, a router doesn't need to remove the EL if the next-hop doesn't
>support it. The only requirement on using EL is: An ingress LSR cannot
>insert ELs for packets going into a given tunnel unless an egress LSR has
>indicated via signaling that it can process ELs on that tunnel.

Can you add a short section referencing the applicable section in this
document. 

>"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."

I was talking more on the level of usage of the capability than
advertisement. Since this is new, there should be any RI LSAs
considerations. 

Thanks,
Acee

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 14 Apr 2016 09:09:03 +0000

Hi Acee,

> Sent: Wednesday, April 13, 2016 8:41 PM
> To: Xuxiaohu; [email-masked]
> Cc: OSPF WG List
> Subject: Re: Signaling Entropy Label Capability Using OSPF -
> >> We will soon be progressing the OSPFv2 SR draft. What is your intent
> >>for this  draft? It is missing:
> >>
> Can you come up with a better name than RLSDC? It appears this would obviate
> the need for the recent MSD proposal but that is a much better name.

RLSDC has been replaced by RLDC (Readable Label Depth Capability) in the latest version. If I understood it correctly, MSD and RLD are used to indicate different things, e.g., the former is used to indicate how many labels to maximum extent could be imposed by the ingress node while the latter is used to indicate how many labels to maximum extent could be read by a intermediate node.

> >>     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?
> >
> >OSPF. As for how these capabilities would be used are actually
> >described in
> >https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label. By
> Can you add a short section referencing the applicable section in this document.

Sure. Do you have any suggest on the text in such section?

> >"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."
> 
> I was talking more on the level of usage of the capability than advertisement.
> Since this is new, there should be any RI LSAs considerations.

The EL capability is used by ingress LSRs to determine whether an EL could be inserted into a given LSP tunnel, and the RLD capability is used by ingress LSRs to determine whether it's necessary to insert an EL for a given LSP tunnel in the case where there has already been at least one EL in the label stack. The above has been mentioned in the Introduction section. I'm not sure that I fully understood your point. If not, could you give any suggestion on the discussion of backward compatibility?

Best regards,
Xiaohu (Tiger)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Apr 2016 11:21:54 +0000

Hi Tiger, 

On 4/14/16, 5:09 AM, "Xuxiaohu" <[email-masked]> wrote:

>>obviate
>RLSDC has been replaced by RLDC (Readable Label Depth Capability) in the
>latest version. If I understood it correctly, MSD and RLD are used to
>indicate different things, e.g., the former is used to indicate how many
>labels to maximum extent could be imposed by the ingress node while the
>latter is used to indicate how many labels to maximum extent could be
>read by a intermediate node.

Ok - this will be clearer once the usage section is added. I like RLDC
better than RLSDC. 

>Sure. Do you have any suggest on the text in such section?

I could write this but you think with 5 authors for a draft that only has
1 1/2 pages of content - one of you would be able to write this.

>>advertisement.
>The EL capability is used by ingress LSRs to determine whether an EL
>could be inserted into a given LSP tunnel, and the RLD capability is used
>by ingress LSRs to determine whether it's necessary to insert an EL for a
>given LSP tunnel in the case where there has already been at least one EL
>in the label stack. The above has been mentioned in the Introduction
>section. I'm not sure that I fully understood your point. If not, could
>you give any suggestion on the discussion of backward compatibility?

What happens if not all routers in the domain support capability
advertisement? 

Thanks,
Acee

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 18 Apr 2016 08:35:40 +0000

Hi Acee,

> Sent: Thursday, April 14, 2016 7:22 PM
> >> >> We will soon be progressing the OSPFv2 SR draft. What is your
> >> >>intent for this  draft? It is missing:
> >> >>
> >>obviate  the need for the recent MSD proposal but that is a much
> >>better name.
> >
> >RLSDC has been replaced by RLDC (Readable Label Depth Capability) in
> >the latest version. If I understood it correctly, MSD and RLD are used
> >to indicate different things, e.g., the former is used to indicate how
> >many labels to maximum extent could be imposed by the ingress node
> >while the latter is used to indicate how many labels to maximum extent
> >could be read by a intermediate node.
> 
> Ok - this will be clearer once the usage section is added. I like RLDC better than
> RLSDC.

OK, will add a usage and applicability section.

> >
> >> >>     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?
> >> >
> >> >This document only describes how the ELC and RLSDC are advertised
> >> >via OSPF. As for how these capabilities would be used are actually
> >> >described in
> >> >the way, a router doesn't need to remove the EL if the next-hop
> >> >doesn't support it. The only requirement on using EL is: An ingress
> >> >LSR cannot insert ELs for packets going into a given tunnel unless
> >> >an egress LSR
> >>has

Fine:)

> >> >"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."
> >>
> >could be inserted into a given LSP tunnel, and the RLD capability is
> >used by ingress LSRs to determine whether it's necessary to insert an
> >EL for a given LSP tunnel in the case where there has already been at
> >least one EL in the label stack. The above has been mentioned in the
> >Introduction section. I'm not sure that I fully understood your point.
> >If not, could you give any suggestion on the discussion of backward
> compatibility?
> 
> What happens if not all routers in the domain support capability advertisement?

If a given egress node doesn't support ELC, ingress nodes should not insert EL into the tunnels towards that egress node. If some routers don't support RLDC, the EL insertion approach as described in Section 5.4.  (a.k.a., ELs at readable label stack depths) of (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label) may be impacted a little bit. For example, a default RLD value can be set for all those routers that don't advertise the RLDC. Anyway, since this draft is only intended to describe how to advertise ELC and RLDC via OSPF, the specific usage of these capabilities is outside of the scope of this draft. 

Any further comments and suggestions are welcome.

Best regards,
Xiaohu