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

["Acee Lindem (acee)" <[e-mail]>]

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. 


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



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

Thanks,
Acee 


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