Hi Tiger, On 4/14/16, 5:09 AM, "Xuxiaohu" <[email protected]> wrote:
>Hi Acee, > >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:[email protected]] >> Sent: Wednesday, April 13, 2016 8:41 PM >> To: Xuxiaohu; [email protected] >> 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" <[email protected]> wrote: >> >> >Hi Acee, >> > >> >Thanks for your comments. Please see my response in line. >> > >> >> -----Original Message----- >> >> From: Acee Lindem (acee) [mailto:[email protected]] >> >> Sent: Tuesday, April 12, 2016 1:39 AM >> >> To: [email protected] >> >> 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 >> > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
