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

[<[e-mail]>]

Hi Zhenbin,

1. Scalability
   ----------
Your scalability concern is about the SPRING architecture, not this ISIS draft.
Indeed, the deeper label stack brings a cost and in particular an increased requirement on equipments. However this is highly use case, network topology and equipment dependent. Some will definitely find combinations which are doable and which requires this IGP extension. So fact that some combination may not work is IMO not enough to reject the ISIS draft and hence all use cases.

You may also be interested by the following thread about 'source label" in the MPLS working group, where some other contributors believe that this is not an issue. http://www.ietf.org/mail-archive/web/mpls/current/msg11906.html

Bottom line, I don't think that this is a big enough reason to discard all use cases (otherwise, pushing 2 additional labels 15 years ago would probably have been a no go for MPLS VPNs). In particular, I believe that the FRR use case is valid. Hence, even for a subset of the use cases, the ISIS extension is needed.
But I agree that label stack depth is something to be looked at.


> Complex IGP's label allocation method. I think the existing method is not a good way to reserve SRGB and allocate segment index. It is complex and also not scalable. 
You are free to propose alternative method. However, note the draft has been published a year ago (and has been worked on between authors for even more time) and is already the result of lots of work and compromise, from many people.
I don't see why it is no scalable.

> We have implemented similar features to reserve a range of label for specific service.
IMHO, the issue is different between:
- a few transport labels for which the FEC are global in the AS/area
- many services labels which are usually local to a (few) service nodes

2. FRR use case
   ------------
> Regarding the segment routing for FRR, I agree that it is truly a useful usecases
Good. So in short it needs the IGP extension. 

> Since this will cause deeper label stacks, I wonder if your can provide the research result on how often the case will happen in a normal network

http://tools.ietf.org/agenda/88/slides/slides-88-spring-9.pdf provides a small subset:
- for link protection with symmetric link cost: 2 (additional) labels are a maximum whatever the topology
- for node protection, our simulation over 11 ASes indicates that the max is 4 labels, and that 2 labels are enough for more than 99% of the cases.

More details will be presented at the MPLS world congress next week.

> On the other hand we will also do the similar research on the topic.

Good.


3. ISIS extensions
   ---------------

I will leave your comments to the authors of draft-previdi-isis-segment-routing-extensions


Thanks,
Regards,
Bruno


>From: Isis-wg [mailto:[e-mail]] On Behalf Of Lizhenbin
>
>Hi Bruno,
>I am glad to get your response on the topic. Please refer to following my
>reply.
>1. Regarding concern about the scalability issues and the future deployment,
>I have explained in the link http://www.ietf.org/mail-
>archive/web/spring/current/msg00559.html.
>2. Regarding the segment routing for FRR, I agree that it is truly a useful
>usecases and I also read the draft "draft-francois-segment-routing-ti-lfa-
>00" carefully.
>1) My concern is still from "4.4.  Connecting distant P and Q nodes along
>post-convergence paths". Since this will cause deeper label stacks, I wonder
>if your can provide the research result on how often the case will happen in
>a normal network just like the MRT for which Alia, Chris Bowers, etc.,
>provides detailed algorithm analysis based on different typical topologies.
>2) In addition, I still concern about two scenarios about the segment
>routing for FRR:
>-- For the scenarios to be compatible with the existing MPLS LDP network,
>even if the segment routing path is used, LDP remote peer has to be set up
>which will have much effect on the practical deployment.
>-- For the scenarios only using segment routing path, since the primary path
>uses the segment routing path with a list of segments, even if there are not
>many segments in the backup path, the segments in the primary path plus the
>segments in the backup path maybe cause deeper label stacks.
>Regarding my concern about scenarios in 1) and 2), I wish the detailed
>analysis and reasonable solutions from you would  help convince us. On the
>other hand we will also do the similar research on the topic.
>3. Regarding the ISIS extensions, I need some clarification to help
>understand the protocol extensions design:
>1) From my point of view, for better compatibility, I hope all the label
>allocation can use "SID/Label Binding TLV" instead of affect many exiting
>ISIS TLVs. Current ISIS extensions for segment routing will have effect on
>many existing TLVs besides the new TLV "SID/Label Binding TLV", is it just
>for convenience?
>2) Regarding the label allocation, in my presentation in IETF89 ISIS WG for
>draft-li-isis-mpls-multi-topology-00, I explain my opinions:
>-- Decouple segment and label. In Sec 2.1 "SID/Label Sub-TLV", the segment
>and label are mixed together. And it depends length to differentiate. I do
>not think it is a good way. In addition, for the scalability, it is better
>that the label stack should be defined here like label BGP in RFC 3107
>instead of only one label for the TLV. If so, the length is not a good way
>to differentiate.
>-- For the global label allocation method, I explained my concern in
>http://www.ietf.org/mail-archive/web/spring/current/msg00559.html about the
>upgrading issues for the reseved SRGB. If the method cannot convince us
>enough or maybe centrol control is a better way to allocate global label, it
>is early to define the prototol extensions.
>
>I think segment routing will have much effect on the existing network and
>the future network. Until now, there are still existing and mature solutions
>for the usecase proposed for segment routing which may be not perfect as
>claimed comparing with segment routing. On the other hand, more research
>work should be done for segment routing to prove it is truly a good
>alternative. My concern is listed as above, both for segment routing's use
>cases and ISIS extensions for SR. I hope the discussion would help determine
>a better solutions and protocol extensions.
>
>Regards,
>Zhenbin (Robin)
>
>
>
>
>
>________________________________________
>发件人: [e-mail] [[e-mail]]
>发送时间: 2014年3月7日 21:18
>收件人: Lizhenbin
>抄送: [e-mail];
>Christian Hopps; Hannes Gredler; [e-mail] list; [e-mail]
>主题: RE: [Isis-wg] WG acceptance for draft-previdi-isis-segment-routing-
>extensions-05
>
>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.
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

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.