John, Bruno, sorry for having missed that. I’ll resubmit right now. I integrated all comments. Regarding the missing "section 3.1" (referring to the isis draft), I replaced text with the reference to draft-ietf-idr-bgp-ls-segment-routing-ext which defines the bgp-ls tlv for advertising the SRGB. I gave this as an example. I also moved draft-ietf-spring-segment-routing into the normative references section.
Thanks. s. > On Mar 10, 2017, at 8:52 PM, John G.Scudder <j...@juniper.net> wrote: > > Hi Authors, > > I see that yesterday's -10 revision doesn't address Bruno's comments, below. > Can you please either update the document if you accept Bruno's suggestions, > or otherwise discuss them on the list? We can't declare the WGLC to be > satisfactorily finished until this is resolved. > > Thanks, > > --John > >> On Feb 16, 2017, at 11:50 AM, bruno.decra...@orange.com wrote: >> >> Hi, >> >> I’ve read the draft, please find below some minor comments: >> >> --- >> §4.3 >> " * A 4 octet index defining the offset in the SID/Label space >> advertised by this router using the encodings defined in Section 3.1." >> >> - Following the recent addition of the SRLB Label Space, I'd rather have the >> text explicitly refers to name of that Label space. e.g. >> OLD: SID/Label space >> NEW: SRGB >> >> - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess someone >> may imagine using the BGP "Originator SRGB TLV". Then what if the node runs >> multiple IGP with different SRGB configured? >> >> - Note that this document has no "Section 3.1". The text seems borrowed from >> the IS-IS SR draft, hence may be adding the name of this draft would just >> solve the point. (with a normative reference to this IS-IS draft) >> >> --- >> OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by IANA) >> proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1) >> >> (“new” may become unspecific 2 years from now) >> >> --- >> One could probably argue that [I-D.ietf-spring-segment-routing] should be a >> normative reference. >> >> Thanks, >> Regards, >> --Bruno >> >> >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Susan Hares >> Sent: Thursday, February 16, 2017 12:35 AM >> To: i...@ietf.org >> Cc: 'Alvaro Retana (aretana)'; spring@ietf.org >> Subject: [spring] IDR WG 2 week WG LC on >> draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) >> >> This begins a 2 week IDR WG last call on >> draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) There >> are two implementations describe on the wiki at: >> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20 >> >> The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus >> Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The >> authors will indicate on the list and in the wiki the following information : >> >> 1) Were these implementations separate implementations? >> 2) What were the results of the interoperability tests? >> >> This work is linked to the draft-ietf-spring-segment-routing-central-epe >> work in the SPRING WG. Based on the two drafts, the WG should might >> consider: >> 1) Is there need for this work in deployments in networks/ >> 2) Is this technically ready for publication? >> 3) Does it fit with the spring informational draft? >> >> For the ease of reference the web references are below: >> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/ >> >> Sue Hares >> _________________________________________________________________________________________________________________________ >> >> 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. >> >> _______________________________________________ >> Idr mailing list >> i...@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
