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

[Xuxiaohu <[e-mail]>]

Hi Acee,

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[e-mail]]
> Sent: Thursday, April 14, 2016 7:22 PM
> To: Xuxiaohu; [e-mail]
> Cc: OSPF WG List
> Subject: Re: Signaling Entropy Label Capability Using OSPF -
> draft-ietf-ospf-mpls-elc-00
> 
> Hi Tiger,
> 
> On 4/14/16, 5:09 AM, "Xuxiaohu" <[e-mail]> wrote:
> 
> >Hi Acee,
> >
> >> -----Original Message-----
> >> From: Acee Lindem (acee) [mailto:[e-mail]]
> >> Sent: Wednesday, April 13, 2016 8:41 PM
> >> To: Xuxiaohu; [e-mail]
> >> Cc: OSPF WG List
> >> Subject: Re: Signaling Entropy Label Capability Using OSPF -
> >> draft-ietf-ospf-mpls-elc-00
> >>
> >> Hi Tiger,
> >>
> >> On 4/13/16, 3:41 AM, "Xuxiaohu" <[e-mail]> wrote:
> >>
> >> >Hi Acee,
> >> >
> >> >Thanks for your comments. Please see my response in line.
> >> >
> >> >> -----Original Message-----
> >> >> From: Acee Lindem (acee) [mailto:[e-mail]]
> >> >> Sent: Tuesday, April 12, 2016 1:39 AM
> >> >> To: [e-mail]
> >> >> 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:
> >> >>
> >> >>     1. A figure with the RI encoding like other OSPF documents
> >> >
> >> >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.
> >
> >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
> >> >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.
> >
> >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.

Fine:)

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

> Thanks,
> Acee
> 
> 
> >
> >Best regards,
> >Xiaohu (Tiger)
> >
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >> >
> >> >Best regards,
> >> >Xiaohu
> >> >
> >> >> Thanks,
> >> >> Acee
> >> >
> >