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. > >> 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? > > > > >> 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? Best regards, Xiaohu (Tiger) > Thanks, > Acee > > > > > > >Best regards, > >Xiaohu > > > >> Thanks, > >> Acee > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
