Fwd: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra <[e-mail]>]

6MAN only

Brian

I believe your assessment is correct.  The verbiage is very confusing in
the draft.  Probably need to make a Visio diagram of this would be helpful.

Z is the PSP node -one hop before final destination C

Z receives SL=1

When the packet leaves Y, segments-left = 1, list = [C,Z,Y,X], and the
next IPv6 destination is Z. => Ref1 - Z has received SRH has SL=1

Z updates SRH and sends SL=0

When the packet leaves Z, segments-left = 0, list = [C,Z,Y,X], and the
next IPv6 destination is C.

So now on PSP node Z - will get the updated SL and process PSP set below:

1.   IF updated SL = 0 & PSP is TRUE
2.      pop the top SRH


On node C PSP processing:


   When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.


This verbiage is even more confusing and I still don’t understand.  So
this PSP flavor knob can be used on any

end, end.X and end.T function.  I understand the end but not the use
on the end.X or end.T.  So this is a loophole

Spring is creating to be able to do the PSP removal

of the SRH on any P node and not just the 2nd to last

hop PSP node as long as the pseudocode conditions are satisfied with
the SL received and updated value.


https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21


4.21.1 <https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.
PSP: Penultimate Segment Pop of the SRH

   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
   the following instructions must be added:

 1.   IF updated SL = 0 & PSP is TRUE
 2.      pop the top SRH                                         ;; Ref1


Ref1: The received SRH had SL=1.  When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but
   are not processed as part of the function.


As far as RFC 8200 since node Z being the PSP node, it is removing the SRH
so that would be in violation of the spec.

I think the reasons given for PSP still does not make sense to me and I
believe are not valid.  Using my SP technical expertise in MPLS and
applying to SR below.

The doh and AH reason given for PSP function does not make sense since the
encapsulated customer payload would have AH and doh and not the outer v6
header.

As far as legacy hardware not supporting SRH processing does not
technically make sense at all. Since every PE in an SR domain both SRv6 or
SR-MPLS identical to MPLS would be both a SR source node and final
destination node of an LSP.  I am using the MPLS term LSP with SR as the
concept of FEC destination which now is a prefix SID still exists that all
traffic to egress final destination  PE is forwarded to.  Since LSPs to FEC
destination are uni directional and that would be the case as well for SR
paths - the idea that the final destination PE would lack hardware
capability for SRH processing does not make sense as the source and final
destination node are one and the same.

Gyan
---------- Forwarded message ---------
From: Brian E Carpenter <[e-mail]>
Date: Fri, Feb 28, 2020 at 5:52 PM
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
To: <[e-mail]>, draft-ietf-spring-srv6-network-programming
<[e-mail]>, Pablo Camarillo
(pcamaril) <[e-mail]>
CC: SPRING WG List <[e-mail]>


Bruno,

Thanks for this. Please view what follows with a non-proportional font.
Here's my understanding of the scenario we are talking about:

  A -------->B---------->C
  |                      ^
  |                      |
  \                     /
   X-------->Y-------->Z

The normal path is from A to B to C and the packet would be a plain
IPv6 packet with no routing header.

Now assume that node A detects a "link down" condition on the link to B.
Until routing has converged, A (with pre-existing knowledge of the topology)
sends packets to C with a routing header via X, Y and Z.

So what does the routing header look like when the packet leaves A?
Presumably, segments-left = 3, and the list of destinations is [C,Z,Y,X],
and the initial IPv6 destination is X.

When the packet leaves X, segments-left = 2, list = [C,Z,Y,X], and the
next IPv6 destination is Y.

When the packet leaves Y, segments-left = 1, list = [C,Z,Y,X], and the
next IPv6 destination is Z.

When the packet leaves Z, segments-left = 0, list = [C,Z,Y,X], and the
next IPv6 destination is C.

To me this seems to be what is described by RFC8200 and by the approved
draft-ietf-6man-segment-routing-header-26. Is this correct?

In what way is the PSP flavor different (Z being the penultimate hop)?

I have just realised what may be the misunderstanding here. The wording in
RFC8200 may be a bit loose, as Fernando has observed, but the logic of
draft-ietf-spring-srv6-network-programming-10 PSP also depends on looking
at the value of segments-left and only deleting the routing header
if segments-left == 0. The problem is that this test is applied *after*
the node (Z in my example) has already decremented the value of
segments-left.
The text in RFC8200 clearly refers to the incoming value, which is 1
in node Z. The routing header is not exhausted until it reaches a node
whose address is the last one in the list, i.e. C in my example, and
the incoming segments-left == 0.

So, the PSP mechanism is depending on a reading of RFC8200 that ignores
the statement of intent in Appendix B, *and* on testing against the already
decremented value of segments-left, not the incoming value of segments-left.

Now, it may be that there will be IETF rough consensus to allow this but
I think the text needs to be much more explicit about these two points.

(BTW, I am not denying that PSP works, subject to the usual comments
about AH and PMTUD.)

Regards
   Brian Carpenter

On 29-Feb-20 06:19, [e-mail] wrote:
> Pablo, authors, WG,
>
>
>
> Section 4.16.1 [1] is the subject of multiple comments and clarification
questions. Most notably some comments from Brian.
>
>
>
> Its current text is very focused on the technical specification.
Technical specification is good and this is the primary objective to
achieve interoperability. But some would say that it is a bit terse,
especially given the amount of context behind it. So I think that it could
benefit from some introduction text.
>
>
>
> Could you work on some text to better introduce PSP and put it in
context? Possibly working with Brian who is kind enough to work on
improving the clarity of this section for everyone.
>
> Quoting Brian “simply need more explanation in elementary terms”.
>
>
>
> I personally have a few points in mind:
>
> -          Clarifying what “Penultimate” refers to. This is required as
there are multiple reading such “penultimate IPv6/SRv6 transit node” (which
we all agree is not allowed by RFC 8200, so let’s make things clear that
the document is not talking or suggesting or allowing this) or “penultimate
SR Segment Endpoint Node indicated in the IPv6 destination address of the
received IPv6 header”.
>
> -          Clarify what you mean by “Pop”. (as this terminology is
heavily borrowed from MPLS and may not be crystal clear for everyone,
especially since the MPLS RFC is not a normative reference (and it should
not be))
>
> -          Clarify that given the nodes A—B—C,  the PSP flavor is done by
penultimate Segment Endpoint “B” at the request of the IPv6 source node “A”
as an outsourced service from the ultimate SR End Point “C”. “A”, “B” and
“C” been within the same control domain.
>
>
>
> Agreed that this is not changing anything in the spec, and may be obvious
to you, and hopefully clear for people having read the relevant document,
however from the comments it seems clear that some additional context may
help to clarify. Also it’s plausible that some persons may only read this
specific PSP section and react on it.
>
>
>
> Thank you,
>
> --Bruno
>
>
>
> [1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10#section-4.16.1
>
>
>
>
>
> *From:*ipv6 [mailto:[e-mail]] *On Behalf Of *
[e-mail]
> *Sent:* Thursday, December 5, 2019 6:15 PM
> *To:* 'SPRING WG List'
> *Cc:* [e-mail]; draft-ietf-spring-srv6-network-programming
> *Subject:* WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Hello SPRING,
>
>
>
> This email starts a two weeks Working Group Last Call on
draft-ietf-spring-srv6-network-programming [1].
>
>
>
> Please read this document if you haven't read the most recent version,
and send your comments to the SPRING WG list, no later than December 20.
>
>
>
> You may copy the 6MAN WG for IPv6 related comment, but consider not
duplicating emails on the 6MAN mailing list for the comments which are only
spring specifics.
>
>
>
> If you are raising a point which you expect will be specifically debated
on the mailing list, consider using a specific email/thread for this point.
>
> This may help avoiding that the thread become specific to this point and
that other points get forgotten (or that the thread get converted into
parallel independent discussions)
>
>
>
> Thank you,
>
> Bruno
>
>
>
> [1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
>
>
>
>
>
>
_________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>
_________________________________________________________________________________________________________________________
>
> 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.
>

_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]