Understood. Agreed it’s always nice to have options you had even in a legacy protocol I guess eventually mpls would become legacy but I think they both SR and mpls have their advantages and disadvantages but since most folks are familiar with PHP it makes sense to carry forward into SR features that exist in mpls today.
Thank you Gyan Sent from my iPhone > On May 15, 2019, at 1:25 AM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > Gyan - > > I grant that UHP may not be widely used in deployments - but as it is a > supported option when using MPLS we saw no reason to eliminate support for it > in the signaling. > Being able to support it does not require folks to deploy it of course. > > Les > > >> -----Original Message----- >> From: Gyan Mishra <hayabusa...@gmail.com> >> Sent: Tuesday, May 14, 2019 7:23 PM >> To: Mirja Kühlewind <i...@kuehlewind.net> >> Cc: The IESG <i...@ietf.org>; draft-ietf-isis-segment-routing- >> extensi...@ietf.org; Christian Hopps <cho...@chopps.org>; >> uma.chund...@huawei.com; aretana.i...@gmail.com; lsr-cha...@ietf.org; >> lsr@ietf.org >> Subject: Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment- >> routing-extensions-24: (with COMMENT) >> >> >> With SR is PHP P flag really necessary as that was used in with mpls >> historically >> to offload the ultimate hop router from having to pop all labels within the >> label stack but with high end routers these days the legacy PHP does not >> provide any cpu processing gains and with LDP has resulted in issues with >> QOS exp scheduling bits lost in cases where a remark was done on ingress >> the topmost exp bits are not copied to the bottom of stack mpls vpn labels >> thus loss of Critical PHB scheduling. >> >> Workaround had been to enable explicit null or use qos groups internal >> markings to keep the marking intact on the topmost. >> >> >> If the P-flag is not set then any upstream neighbor of the Prefix- >> SID originator MUST pop the Prefix-SID. This is equivalent to the >> penultimate hop popping mechanism used in the MPLS dataplane which >> improves performance of the ultimate hop. MPLS EXP bits of the >> Prefix-SID are not preserved to the ultimate hop (the Prefix-SID >> being removed). If the P-flag is unset the received E-flag is >> ignored. >> >> Gyan Mishra >> Verizon Communications >> Phone: 301 502-1347 >> >> Sent from my iPhone >> >>> On May 14, 2019, at 10:09 PM, Gyan Mishra <hayabusa...@gmail.com> >> wrote: >>> >>> >>> I noticed in the intro that IPv4 is not mentioned just IPv6 and mpls. Was >> that on purpose. >>> >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>> Prefix segments represent an ECMP-aware shortest-path to a prefix (or >>> a node), as per the state of the IGP topology. Adjacency segments >>> represent a hop over a specific adjacency between two nodes in the >>> IGP. A prefix segment is typically a multi-hop path while an >>> adjacency segment, in most of the cases, is a one-hop path. SR’s >>> control-plane can be applied to both IPv6 and MPLS data-planes, and >>> does 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. Still, SR can interoperate in >>> the presence of LSPs established with RSVP or LDP. >>> >>> Gyan Mishra >>> Verizon Communications >>> Phone: 301 502-1347 >>> >>> Sent from my iPhone >>> >>>> On May 14, 2019, at 7:58 AM, Mirja Kühlewind via Datatracker >> <nore...@ietf.org> wrote: >>>> >>>> Mirja Kühlewind has entered the following ballot position for >>>> draft-ietf-isis-segment-routing-extensions-24: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing- >> extensions/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> A few comments/questions: >>>> >>>> 1) For both the Prefix Segment Identifier and the Adjacency Segment >> Identifier >>>> sub-TLV it is not fully clear to me what the value field is used for when >>>> the >>>> V-Flag is set. Can you further elaborate this in the draft or provide a >>>> respective pointer? >>>> >>>> 2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label >> Binding TLV >>>> is only one bit. I'm not expecting a new version of IP any time soon, >> however, >>>> maybe completely different address families could be useful as well. Not >> sure >>>> if only 1 bit is future-proof...? >>>> >>>> 3) Would it make sense to also discuss any risk of leaking information >>>> (e.g. >>>> about the network topology) in the security consideration section? >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
