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

[Curtis Villamizar <[e-mail]>]

A clear problem statement is needed before protocol extensions can be
defined.  For example:

  1.  If node protection of SR paths is desirable, then it may be
      necessary to advertise SRLG.

  2.  If lack of Entropy Label capability (ELC) on a subset of
      interfaces is common, then ELC advertised per LSP is needed.

  3.  etc.

Not yet knowing the set of requirements, it is not possible to define
the protocol solution.  Therefore I don't think this should become a
WG until work in the spring WG progresses further.  It is still fine
to discuss the quality of this document as an individual submission,
but for now it defines a TLV container for which spring WG has not
decided on the content.

There are major differences between the topologies of DC (fat tree)
and the topologies of SP (mesh, commonly interconnected meshes, each
mesh generally sparsely physically connected, but each mesh fully
connected by MPLS).  General type of topology has a major impact on
scalability.  Spring WG problem statement should also be clear about
which of these problem spaces spring resides in.  If both, solutions
must be stable in both.

Once there is a problem statement and framework, it makes more sense
to discuss scalability.

Curtis


In message <[e-mail]>
Lizhenbin writes:

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