+1 Nothing really to add to Les’ comments Regards, Jeff
> On Aug 3, 2018, at 09:32, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > Bruno – > > I appreciate why you suggest per-prefix signaling for ELC, but I would prefer > that we not employ that model. > > ELC is clearly a node capability – signaling it in per node scope is > therefore most appropriate. And it aligns with the SR model where we do not > need to depend on hop-by-hop signaling as in the LDP case. > > As regards the interarea issues you raise: > > Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF) support > domain-wide flooding scope. This is not a new capability – though I do agree > with you that the ELC drafts should explicitly mention the flooding scope > requirement. > > As regards identifying the source of a prefix advertisement domain-wide, > IS-IS has a complete solution for this as defined in RFC 7794. > OSPF is lacking support for advertising the source Router-ID, but this can be > easily remedied by defining an extension using Extended Prefix LSA (as has > been mentioned by Peter in another thread). And this functionality is needed > for other reasons e.g., to know when PHP should/should not be done. So it is > probably past time when this should be defined. > > So I think it is better if we use the per-node ELC scope proposed in the ELC > drafts. > > As an aside, I would prefer that we utilize the existing TE Node Capability > Descriptor registry defined in RFC 5073 rather than invent a new > codepoint/registry (the proposed Non-IGP Functional Capabilities registry) – > but that is a minor point. > > Les > > > From: Lsr <[email protected]> On Behalf Of [email protected] > Sent: Friday, August 03, 2018 12:46 AM > To: 徐小虎(义先) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt > > Hi Xiaohu, > > Thanks for the reply. > You seem to assume/require that (router) capability advertisement be > propagated across IGP areas/domains. If so, > - this is a new requirement for existing multi-area networks that need to be > indicated in the draft > - I find this debatable. This point should be explicitly discussed. I’d > rather advertise the ELC capability on a per Segment basis. This would also > be better aligned with RFC 6790 hence safer if EL extensions are defined.. > The (Segment Routing) Prefix-SID sub-TLV has 2 flags remaining. This may be a > good candidate as this information seems SR specific. Alternatively, RFC7794 > may be used. > > Thanks > Best regards, > --Bruno > > From: Lsr [mailto:[email protected]] On Behalf Of ???(??) > Sent: Friday, August 03, 2018 4:13 AM > To: Lsr; [email protected] > Cc: [email protected] > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt > > Hi Bruno, > > Thanks for raising this important issue. > > In fact, the Routable IP Address TLVs/sub-TLVs as described in > (https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02) and > (https://tools..ietf.org/html/draft-xu-isis-routable-ip-address-01) > respectively were intended to address the problem that you had mentioned > (i.e., it is required for OSPF routers in one area to find correlations > between routable IP addresses and capabilities of OSPF routers in another > area). > > The following text is quoted from > > " There are several situations where it is required for OSPF routers in > one area to find correlations between routable IP addresses and > capabilities of OSPF routers in another area. One example is the > Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc] > across the OSPF domain. In this example, assume the ELC TLV > originated by a router in one area is propagated to another area. > Those routers in the latter area need to find routable IP addresses > of the router originating that ELC TLV before inserting the Entropy > Label (EL) for packets going to the Label Switch Path (LSP) tunnel > towards one of the above routable IP addresses..." > > Later, such correlation requirement in the ISIS domain was addressed by > introducing the source IPv4/IPv6 router ID sub-TLVs into the Extended > Reachability TLVs (see https://tools.ietf.org/html/rfc7794). I forget whether > the same extension to OSPF as RFC7794 has been done. > > Best regards, > Xiaohu > ------------------------------------------------------------------ > From:bruno.decraene <[email protected]> > Send Time:2018年8月3日(星期五) 04:50 > To:[email protected] <[email protected]> > Cc:[email protected] <[email protected]> > Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt > > Hi authors, > > "4. Advertising ELC Using IS-IS > > One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired) > is to be assigned by the IANA for the ELC [RFC6790]." > > RFC6790 defines ELC capability on a per FEC/LSP egress basis. > Please defines what you mean exactly with this per node capability. If this > is expected to advertise ELC capability in spring networks, it's not crystal > clear to me how it works in multi-area/domain network with IP prefix/SID > redistribution. > Possibly the ELC flag would need to be advertised on a per prefix basis. > > Thanks, > Regards, > --Bruno > > > > -----Original Message----- > > From: Lsr [mailto:[email protected]] On Behalf Of > [email protected] > > Sent: Thursday, August 02, 2018 10:24 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt > > > > Hi authors, > > > > Please find below some minor comments: > > > > 1) Abstract: > > " In addition, this document introduces the Non-IGP Functional > > Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP > > functional capabilities. ELC is one of such non-IGP functional > > capabilities." > > > > It's a matter of opinion but reducing the number of occurrences of " > non-IGP functional > > capabilities" may improve the S/N ration. > > > > 2) > > The format of the Router Non-IGP Functional Capabilities Sub-TLV is as > follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=TBD1 | Length=4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The sub-TLV is not hard coded/defined with a length of 4, hence this value > should not be part of > > the definition. > > > > 3) > > "Length: Indicates the length of the value portion in octets and will be > a multiple of 4 octets" > > > > Possibly :s/will/MUST > > Please specify the error handling. (e.g. disregards the whole sub-TLV, > disregards the last 1 to 3 > > octets, accept the whole sub-TLV...) > > > > > > 4) > > "One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired) is > to be assigned by the > > IANA for the ELC [RFC6790]." > > > > Since this document defines the new sub-TLV, it can freely do any > allocation itself. > > > > 5) > > "The registration procedure is "Expert Review" as defined in [RFC8126]." > > > > You may want to read RFC 8126 > https://tools.ietf.org/html/rfc8126#section-4.5 > > Which, In particular, states: > > " The registry's > > definition needs to make clear to registrants what information is > > necessary. > > > > [...] > > > > The required documentation and review criteria, giving clear guidance > > to the designated expert, should be provided when defining the > > registry. It is particularly important to lay out what should be > > considered when performing an evaluation and reasons for rejecting a > > request. It is also a good idea to include, when possible, a sense > > of whether many registrations are expected over time, or if the > > registry is expected to be updated infrequently or in exceptional > > circumstances only. " > > > > 6) > > "This capability, referred to as Entropy Readable Label Depth (ERLD) as > defined in [I-D.ietf- > > mpls-spring-entropy-label] " > > > > This probably calls for this document to be a normative reference. > > > > > > " A new MSD-type of the Node MSD b-TLV > > [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to > > advertise the ERLD of a given router." > > > > May be adding the reference to the document defining the ERLD: > > OLD: advertise the ERLD > > NEW: advertise the ERLD [I-D.ietf-mpls-spring-entropy-label] > > > > 7) > > "If a router has > > multiple line cards, the router MUST NOT announce the ELC [RFC6790] > > unless all of its linecards are capable of processing ELs." > > > > May be you mean > > OLD: all of its linecards > > OLD: all of the linecards of the links advertised as IS-IS adjacencies. > > > > Regards, > > --Bruno > > > > > -----Original Message----- > > > From: Lsr [mailto:[email protected]] On Behalf Of > [email protected] > > > Sent: Tuesday, July 31, 2018 4:07 PM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Link State Routing WG of the IETF. > > > > > > Title : Signaling Entropy Label Capability and > Entropy Readable Label Depth Using > > > IS-IS > > > Authors : Xiaohu Xu > > > Sriganesh Kini > > > Siva Sivabalan > > > Clarence Filsfils > > > Stephane Litkowski > > > Filename : draft-ietf-isis-mpls-elc-05.txt > > > Pages : 7 > > > Date : 2018-07-29 > > > > > > Abstract: > > > Multiprotocol Label Switching (MPLS) has defined a mechanism to load > > > balance traffic flows using Entropy Labels (EL). An ingress Label > > > Switching Router (LSR) cannot insert ELs for packets going into a > > > given tunnel unless an egress LSR has indicated via signaling that it > > > has the capability of processing ELs, referred to as Entropy Label > > > Capability (ELC), on that tunnel. In addition, it would be useful > > > for ingress LSRs to know each LSR's capability of reading the maximum > > > label stack depth and performing EL-based load-balancing, referred to > > > as Entropy Readable Label Depth (ERLD), in the cases where stacked > > > LSPs are used for whatever reasons. This document defines mechanisms > > > to signal these two capabilities using IS-IS. These mechanisms are > > > useful when the label advertisement is also done via IS-IS. In > > > addition, this document introduces the Non-IGP Functional > > > Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP > > > functional capabilities. ELC is one of such non-IGP functional > > > capabilities. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05 > > > https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-05 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-mpls-elc-05 > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > __________________________________________________________________________ > > _______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou > > privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par > > erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant > > susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may > > be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and > > its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed > > or falsified. > > Thank you. > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
