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 <hayabusagsm@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 <noreply@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