Re: [Isis-wg] WG acceptance for draft-previdi-isis-segment-routing-extensions-05

[<[e-mail]>]

Hi Zhenbin,

You are right that the segment routing specifications are not finished and needs further refinements. However, this is not WG last call, but WG adoption. IMO, adopting draft-previdi-isis-segment-routing-extensions is the best way to have the IETF ISIS WG helps refining this document.

I really don't think it's too early. IIRC, the doc is 1 year old now (since Orlando), and multiple implementations are underway. IMHO the more we would wait, the less chance for the IETF participants (including you) to be able to contribute and influence the document, because once implementations are done, people are more reluctant to make non compatible /significant changes.

Regarding your doubt about scalability,
- if they concern this document (ISIS extension), it would be useful if you could provide a more specific feedback about this.
- if they do not concern this ISIS document, but rather a/some Segment Routing uses cases, it would probably be better to raise them in the spring working under a thread topic specific to the related draft/use case. In particular, if you believe that the FRR use case or solution raise "scalability issue" or "doubt about future deployment" I would be interested in the topic.

Thanks,
Regards,
Bruno

>-----Original Message-----
>From: spring [mailto:[e-mail]] On Behalf Of Lizhenbin
>Sent: Thursday, March 06, 2014 11:11 AM
>To: Hannes Gredler; [e-mail] list; [e-mail]
>Cc: [e-mail]; Christian
>Hopps
>Subject: [spring] ??: [Isis-wg] WG acceptance for draft-previdi-isis-
>segment-routing-extensions-05
>
>Hi,
>
>I wonder if it is too early to ask for WG acceptence for draft-previdi-isis-
>segment-routing-extensions-05.
>1. From the point of standardization view
>1) We all know draft-previdi-isis-segment-routing-extensions-05 is not an
>independent draft. There is still doubt about the scalability issue and
>future deployment of segment routing. Even if it can be ignored, when focus
>on the SR's own solutions, There is still much discussion about the usecase
>and architecture on segment routing. Even the important drafts draft-
>filsfils-rtgwg-segment-routing-use-cases/draft-filsfils-rtgwg-segment-
>routing are still in RTGWG WG instead of SPRING WG.
>2) According to draft-filsfils-rtgwg-segment-routing, there are  IGP-Prefix
>Segment/IGP-Node Segment/IGP-Anycast Segment/IGP-Adjacency Segment. There
>seems to be service segment in the future version. In draft-previdi-isis-
>segment-routing-extensions, it seems not all these segments are covered. On
>the other hand, there is much description about ERO TLV in draft-previdi-
>isis-segment-routing-extensions while the ERO/Backup ERO is not explictly
>mentioned in draft-filsfils-rtgwg-segment-routing. I doubt all the
>inconsistency can be matched automatically.
>
>2. From the point of MPLS view
>As claimed in the draft
>"
>SR's
>   control-plane can be applied to both IPv6 and MPLS data-planes, and
>   do not require any additional signaling (other than the regular IGP).
>   For example, when used in MPLS networks, SR paths do not require any
>   LDP or RSVP-TE signaling.
>",
>if ISIS for segment routing is thought as a good replacement for LDP or
>RSVP-TE, I recommend please refer to RFC5036(LDP Specification) which, I
>think, is an excellent example on how to define a good label distribution
>protocol. In ISIS extensions, I cannot see enough description on protocol
>procedures. I may understand the label mapping for prefix/adjacency, but
>regarding label withdraw/release or possible error process, I doubt all
>these precedures could be self-explained.
>
>3. From the point of Implementation view
>As an engineer, I understand the draft on protocol extensions should be
>regarded as the detailed design to be used as a good guidance for the
>implementation and interoperability test. Until now, it seems the scope is
>conflicted and the precedures are not detailed enough for draft-previdi-
>isis-segment-routing-extensions-05. As to the implementation and incoming
>interoperation test claimed, I have much doubt. Maybe it can work, it should
>be refleced in the draft firstly, but not be accepted firstly.
>
>Regards,
>Zhenbin(Robin) Li
>
>
>> -----Original Message-----
>> From: Isis-wg [mailto:[e-mail]] On Behalf Of Hannes
>Gredler
>> Sent: Wednesday, March 05, 2014 4:35 AM
>> To: [e-mail] list
>> Cc: [e-mail];
>Christian
>> Hopps
>> Subject: [Isis-wg] WG acceptance for draft-previdi-isis-segment-routing-
>> extensions-05
>>
>> hi,
>>
>> the authors of draft-previdi-isis-segment-routing-extensions are asking
>> for acceptance as a WG item.
>> http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-
>05
>>
>> please provide feedback, (support/opposition) up until March 19th 2014 (2
>> weeks).
>>
>> thanks,
>>
>> /hannes & chris
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isis-wg
>
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/isis-wg
>_______________________________________________
>spring mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

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.