Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Alvaro Retana]

On February 18, 2022 at 10:53:20 AM, Ketan Talaulikar wrote:

Hi!

We're still not on the same page.


[Cut the indentation to make it more readable.]

> > > > --
> > > > DISCUSS:
> > > > --
> > > >
> > > > Clearly (from looking at rfc8986), not all endpoint behaviors apply to
> > > > the services defined in this document. Should a receiver accept any
> > > > endpoint behavior? What should a receiver do if a known but unrelated
> > > > behavior (End, for example) is received?
> > ...
> > > > For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick
> > > > one), should the behaviors used "in practice" be enforced? What if
> > > > different behavior is advertised? Can it safely be ignored?
> >
> > These two are related: Should only specific behaviors (per service) be
> > accepted?
> >
> > If yes, I need you to specify which are those behaviors and what
> > happens if a different (known) one is received.
> >
> > If no, what does it mean for the service if an unrelated behavior is
> > advertised?
>
> KT> So, this would be a result of a bug (?) on the egress PE that signals a
> wrong behavior. Since the receiver is not validating, the service traffic
> would still arrive at the egress PE but the handling might be erroneous due
> to wrong behavior. The issue still manifests on the egress PE due to its bug.
> Somewhat similar to what might happen if the egress PE were to signal a label
> associated with a wrong context/service as a VPN label in MPLS VPNs.

Verifying that a label is correct is not the same as confirming that
the Behavior is plausible for the service.

I understand how the ingress PE cannot validate an unknown Behavior,
but not validating a known Behavior is not right.  If the Behavior is
unknown, the ingress doesn't have any idea of what the egress may do,
but if the Behavior is known, it does!

§2 lists Behaviors that may correspond to L2/L3 Services.   The
subsections in §5 and §6 list the Endpoint Behaviors used "in
practice" for each of the services.

This is what I would like to see:  For example, §5.1 (IPv4 VPN Over
SRv6 Core) says that "In practice, the SRv6 Endpoint behavior is
End.DX4 or End.DT4."  The ingress PE should then be able to validate
that the Endpoint Behavior is one of these...and take appropriate
actions if it isn't.  Why is that not the case?  Not taking this
simple step opens up (as you mention) the possibility of a bug
creeping in, but also the ability of the egress to signal any behavior
which could result in an unexpected or incorrect action.

This type of checking is the minimum that should be done.



...
> > > > --
> > > > COMMENT:
> > > > 
...
> KT> I believe we were discussing the part of the "SID being routable" as in
> via routing protocol (i.e. IGP/BGP transport). The next paragraph is one that
> covers the base BGP "resolvability" part and does elaborate on the various
> mechanisms like "alternate steering mechanisms" (e.g. any tunnel, SR Policy,
> etc.).

Yes (let me reset a little) -- this is the current text (from §5):

   The SRv6 Service SID SHOULD be routable within the AS of the egress
   PE and serves the dual purpose of providing reachability between
   ingress PE and egress PE while also encoding the SRv6 Endpoint
   behavior.

   When steering for SRv6 services is based on shortest path forwarding
   (e.g., best-effort or IGP Flexible Algorithm
   [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE
   encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header
   (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where
   the destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.  The resolvability
   is evaluated as per [RFC4271].  If the SRv6 SID is reachable via more
   than one forwarding table, local policy is used to determine which
   table to use.  The result of an SRv6 Service SID resolvability (e.g.,
   when provided via IGP Flexible Algorithm) can be ignored if the
   ingress PE has a local policy that allows an alternate steering
   mechanism to reach the egress PE.  The details of such steering
   mechanisms are outside the scope of this document.


My point is that it is a requirement for the SID to be reachable --
independent of how it is resolved: IGP, BGP, "alternate steering
mechanisms", etc.  Otherwise it can't be used.

If we agree with that then the requirement should be reflected in the
text: s/SHOULD/MUST/g


Thanks!

Alvaro.

___
BESS mailing list
BESS@ietf.org

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Robert,

> On Feb 16, 2022, at 5:02 PM, Robert Raszuk  wrote:
> 
> 
> Hi John,
> 
> As you have quoted my note in point #4 I feel that I need to comment on it. 

Thank you for doing so!

> So yes original discussions and major contributions of this work were 
> focusing on VPN use case and I admit when carefully re- reading it to find 
> some text there beyond VPN use case. 
> 
> So we discussed it among co-authors. The point of adding 5.3 & 5.4 is 
> targeting the networks where Internet routes are not present at each node and 
> network uses summarization of infrastructure routes (no end to end /128 
> leaking in the IGP). 
> 
> The text perhaps may require some clarification that use of SAFI 1 is left 
> for the operators to choose if the attribute should be attached to Internet 
> routes - when operator is offering an IP transit or it can be attached just 
> to next hops which are part of the infrastructure. Let's also not forget that 
> if this is IP transit in most networks you can reach all hops along the path 
> anyway (modulo transit SP/ISP policy). 

It’s not 100% clear from your reply, so let me try to paraphrase and you can 
correct any misunderstandings: you’re now in agreement that Sections 5.3 and 
5.4 should be retained, provided that some clarification (that you briefly 
sketch above) is added to the document. Should we expect a revision with the 
clarifications you are talking about? 

Assuming that’s the plan, I agree this point can be closed pending the revised 
text.

> I think major concern expressed from Warren was the potential compromise to 
> the VPNs when SID demuxing it would leak. Well as we know SAFI 128 or 70 are 
> not public. Yes customer may advertise his routes to SAFI 1 and leak but no 
> one has control over it and it is orthogonal to what happens in the SP 
> network. 

This is discussed in my previous reply, to Ketan.

Thanks,

—John

> With that I think that #3 and #4 are no longer a concern. 
> 
> Best regards,
> Robert
> 
> 
> On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker 
>  wrote:
>> John Scudder has entered the following ballot position for
>> draft-ietf-bess-srv6-services-11: Discuss
>> 
>> 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/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> 1. The shepherd writeup for this document says “It also received an RTG DIR
>> review and cross-reviewed with the IDR working group”. Searching in my IDR
>> inbox and the IDR mailing list archives, I don’t find any sign of the
>> cross-review — can you please point me to it?
>> 
>> 2. One area of concern I would have hoped IDR might have looked into is, the
>> document makes a creative use of the MPLS Label field of the NLRI to carry 
>> the
>> Function part of the SID. This means the SID is effectively split across the
>> NLRI and the Prefix-SID attribute. What are the potential error modes if the
>> Prefix-SID attribute should be lost from the route, while the NLRI is 
>> retained?
>> 
>> (An obvious way of addressing this particular concern would be to define a 
>> new
>> NLRI type with the desired semantics, instead of creatively repurposing 
>> fields
>> within an existing NLRI type contrary to their definitions. Such an NLRI type
>> would, for example, presumably state in its specification that if it was
>> received without an accompanying Prefix-SID attribute, that would constitute 
>> an
>> error.)
>> 
>> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
>> discussion turned quickly to the assertion that no, they don’t, in VPN 
>> address
>> families. Let’s accept that claim for the sake of conversation. It’s still 
>> the
>> case that sometimes (often?) routes are distributed from VPN address families
>> into the Global Internet table. When this is done, by default, all the path
>> attributes come along for the ride. Anyone who thinks this is just a
>> hypothetical case might want to look back to (for example) significant 
>> network
>> outages that were caused around a decade ago by leakage of BGP Attribute 128
>> (ATTR_SET, RFC 6368) into the global Internet.
>> 
>> The SIDs contained in these if-they-were-to-leak routes potentially give an
>> attacker a means of directing packets into a VPN customer’s internal network.
>> 
>> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG]
>> consensus”; however, there doesn’t seem to be consensus even 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Ketan,

> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar  wrote:
> 
>> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
>> discussion turned quickly to the assertion that no, they don’t, in VPN 
>> address
>> families. Let’s accept that claim for the sake of conversation. It’s still 
>> the
>> case that sometimes (often?) routes are distributed from VPN address families
>> into the Global Internet table. When this is done, by default, all the path
>> attributes come along for the ride. Anyone who thinks this is just a
>> hypothetical case might want to look back to (for example) significant 
>> network
>> outages that were caused around a decade ago by leakage of BGP Attribute 128
>> (ATTR_SET, RFC 6368) into the global Internet.
>> 
>> The SIDs contained in these if-they-were-to-leak routes potentially give an
>> attacker a means of directing packets into a VPN customer’s internal network.
>> 
> KT> I believe we are getting now into implementation aspects when you bring 
> up handling of attributes during redistribution from VPN tables into the 
> default table.

I don’t think we can sweep this easily under the “it’s an implementation 
detail” rug — the fact is, AFAIK this *is* what implementations do 
(redistribute optional transitive attributes from VPN to default tables). This 
“implementation detail” is not, itself, an issue for 
draft-ietf-bess-srv6-services. What it is, is a perspective on "Precaution 
should be taken to ensure that the BGP service information (including 
associated SRv6 SID) advertised via BGP sessions are limited to peers within 
this trusted SR domain.” The argument was previously advanced that this is 
trivially achieved for VPN address families, I’m saying that’s not so, for the 
reasons given, and therefore the ramifications of leaks of the information you 
identify as sensitive, need to be considered (at minimum).

> We can add some text in the security considerations to discuss this.

Looking forward to seeing it, thank you.

—John
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi John,

Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI
> registry. Shouldn’t this be renamed? I mean, I guess it should have been
> renamed as of RFC 8365, but better late than never. I’m not sure quite what
> the name should become, but “MPLS-labeled” is manifestly wrong. Even
> “labeled” is wrong since the thing you’re stuffing in there isn’t a label.
> Since you’re the last one to touch it :-) if we can agree a better name for
> the SAFI I think it would be appropriate to add that to your IANA
> Considerations.
>

My suggestion would be: "VPN address & context"  or "Context & VPN address"

Thx,
R.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Ketan,

> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar  wrote:
> 
>> 2. One area of concern I would have hoped IDR might have looked into is, the
>> document makes a creative use of the MPLS Label field of the NLRI to carry 
>> the
>> Function part of the SID. This means the SID is effectively split across the
>> NLRI and the Prefix-SID attribute. What are the potential error modes if the
>> Prefix-SID attribute should be lost from the route, while the NLRI is 
>> retained?
>> 
>> (An obvious way of addressing this particular concern would be to define a 
>> new
>> NLRI type with the desired semantics, instead of creatively repurposing 
>> fields
>> within an existing NLRI type contrary to their definitions. Such an NLRI type
>> would, for example, presumably state in its specification that if it was
>> received without an accompanying Prefix-SID attribute, that would constitute 
>> an
>> error.)
>> 
> KT> This document follows the approach similar as taken for extending MPLS 
> EVPN RFC7432 by RFC8365.

I take it you’re referring to RFC 8365 §5.1.3 which talks about using the MPLS 
Label field (or MPLS1 Label field) to carry the VNI in the presence of a BGP 
Encapsulation Extended Community? Yes, that seems like a pretty close analogue. 
And given this particular trick is only with VPN-type address families one can 
also argue that there’s not a risk of affected routes leaking into the big-I 
Internet, which is the typical associated concern. 

Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI 
registry. Shouldn’t this be renamed? I mean, I guess it should have been 
renamed as of RFC 8365, but better late than never. I’m not sure quite what the 
name should become, but “MPLS-labeled” is manifestly wrong. Even “labeled” is 
wrong since the thing you’re stuffing in there isn’t a label. Since you’re the 
last one to touch it :-) if we can agree a better name for the SAFI I think it 
would be appropriate to add that to your IANA Considerations.

Thanks,

—John

P.S.: Thank you for your diplomacy in not pointing to RFC 9012 as your example 
of a prior use of this pattern. ;-)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Review request for draft-ietf-bess-srv6-services-11

[Bocci, Matthew (Nokia - GB)]

IDR WG

Please note that the deadline for comments is Friday 4th March, NOT 26th Feb.

Matthew


From: Idr  on behalf of Bocci, Matthew (Nokia - GB) 

Sent: Friday, February 18, 2022 6:52 pm
To: i...@ietf.org
Cc: ; draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [Idr] Review request for draft-ietf-bess-srv6-services-11

IDR Working Group

This draft has completed working group last call in the BESS working group and 
is currently being reviewed by the IESG.

We would appreciate review and comments by participants in the IDR working 
group.

The latest version of the draft is available here:  
draft-ietf-bess-srv6-services-11 - SRv6 BGP based Overlay 
Services

Please send any comments in reply to this thread by 26th February 2022.

Thank you,

Matthew
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Review request for draft-ietf-bess-srv6-services-11

[Bocci, Matthew (Nokia - GB)]

IDR Working Group

This draft has completed working group last call in the BESS working group and 
is currently being reviewed by the IESG.

We would appreciate review and comments by participants in the IDR working 
group.

The latest version of the draft is available here:  
draft-ietf-bess-srv6-services-11 - SRv6 BGP based Overlay 
Services

Please send any comments in reply to this thread by 26th February 2022.

Thank you,

Matthew
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

Thanks. A couple weeks is just fine.

—John

On Feb 18, 2022, at 12:44 PM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:


Hi John

I’ll send a note to the IDR list requesting review - is a couple of weeks 
sufficient?



Matthew


From: John Scudder mailto:j...@juniper.net>>
Sent: Friday, February 18, 2022 5:29:57 PM
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>;
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>; The IESG 
mailto:i...@ietf.org>>; bess@ietf.org 
mailto:bess@ietf.org>>; 
idr-cha...@ietf.org 
mailto:idr-cha...@ietf.org>>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)

After sleeping on it I was too hasty in saying “water under the bridge” and 
moving on.

I’d like to request that you correct the oversight and seek input from IDR — 
what would have happened if the document had been cross-WGLC’d with IDR. 
Possibly this will result in no input (that happens sometimes) of course. But, 
if you start now, I don’t anticipate it will turn into the long pole for moving 
the document forward.

Thanks,

—John

On Feb 17, 2022, at 2:15 PM, John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>> 
wrote:


Thanks, Matthew. I didn’t think of searching for it under the individual 
submission name; when I read “cross-reviewed” I interpreted that as WGLC, not 
WG adoption.

It looks to me as though there was no reply to the notification message you 
reference, do you agree? (Of course there might have been people who commented 
on the BESS list, but I don’t see anything cc’d to IDR.)

It does seem to me as though, considering the unusually close association 
between this spec and an active IDR draft, it would have made sense to 
cross-WGLC it, including a specific pointer to the overlap. I mean, I 
acknowledge that might have come to nothing since there’s considerable overlap 
between the groups — but it’s not universal overlap. Anyway, it’s water under 
the bridge now.

I’ve added the IDR chairs to the cc just in case any of them want to comment.

Regards,

—John

On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:



Hi John

Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 
(ietf.org)


Regards

Matthew

From: John Scudder via Datatracker mailto:nore...@ietf.org>>
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-bess-srv6-services-11: Discuss

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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMMUd9RiSA$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMPLJdcbPg$



--
DISCUSS:
--

1. The shepherd writeup for this document says “It also received an RTG DIR
review and cross-reviewed with the IDR working group”. Searching in my IDR
inbox and the IDR mailing list archives, I don’t find any sign of the
cross-review — can you please point me to it?

2. One area of concern I would have hoped IDR might have looked into is, the
document makes a creative use of the MPLS Label field of the NLRI to carry the
Function part of the SID. This means the SID is effectively split across the
NLRI and the Prefix-SID attribute. What are the potential error modes if the
Prefix-SID attribute should be lost from the route, while the 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Bocci, Matthew (Nokia - GB)]

Hi John

I’ll send a note to the IDR list requesting review - is a couple of weeks 
sufficient?



Matthew


From: John Scudder 
Sent: Friday, February 18, 2022 5:29:57 PM
To: Bocci, Matthew (Nokia - GB) 
Cc: draft-ietf-bess-srv6-servi...@ietf.org 
; bess-cha...@ietf.org 
; The IESG ; bess@ietf.org 
; idr-cha...@ietf.org 
Subject: Re: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)

After sleeping on it I was too hasty in saying “water under the bridge” and 
moving on.

I’d like to request that you correct the oversight and seek input from IDR — 
what would have happened if the document had been cross-WGLC’d with IDR. 
Possibly this will result in no input (that happens sometimes) of course. But, 
if you start now, I don’t anticipate it will turn into the long pole for moving 
the document forward.

Thanks,

—John

On Feb 17, 2022, at 2:15 PM, John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>> 
wrote:


Thanks, Matthew. I didn’t think of searching for it under the individual 
submission name; when I read “cross-reviewed” I interpreted that as WGLC, not 
WG adoption.

It looks to me as though there was no reply to the notification message you 
reference, do you agree? (Of course there might have been people who commented 
on the BESS list, but I don’t see anything cc’d to IDR.)

It does seem to me as though, considering the unusually close association 
between this spec and an active IDR draft, it would have made sense to 
cross-WGLC it, including a specific pointer to the overlap. I mean, I 
acknowledge that might have come to nothing since there’s considerable overlap 
between the groups — but it’s not universal overlap. Anyway, it’s water under 
the bridge now.

I’ve added the IDR chairs to the cc just in case any of them want to comment.

Regards,

—John

On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:



Hi John

Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 
(ietf.org)


Regards

Matthew

From: John Scudder via Datatracker mailto:nore...@ietf.org>>
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-bess-srv6-services-11: Discuss

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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMMUd9RiSA$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMPLJdcbPg$



--
DISCUSS:
--

1. The shepherd writeup for this document says “It also received an RTG DIR
review and cross-reviewed with the IDR working group”. Searching in my IDR
inbox and the IDR mailing list archives, I don’t find any sign of the
cross-review — can you please point me to it?

2. One area of concern I would have hoped IDR might have looked into is, the
document makes a creative use of the MPLS Label field of the NLRI to carry the
Function part of the SID. This means the SID is effectively split across the
NLRI and the Prefix-SID attribute. What are the potential error modes if the
Prefix-SID attribute should be lost from the route, while the NLRI is retained?

(An obvious way of addressing this particular concern would be to define a new
NLRI type with the desired semantics, instead of creatively repurposing fields
within an existing NLRI type contrary to their definitions. Such an NLRI type
would, for example, presumably state in its specification that if it was
received without an accompanying Prefix-SID attribute, that would constitute an
error.)

3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
discussion turned quickly to the assertion that no, they don’t, in VPN address
families. Let’s accept 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

After sleeping on it I was too hasty in saying “water under the bridge” and 
moving on.

I’d like to request that you correct the oversight and seek input from IDR — 
what would have happened if the document had been cross-WGLC’d with IDR. 
Possibly this will result in no input (that happens sometimes) of course. But, 
if you start now, I don’t anticipate it will turn into the long pole for moving 
the document forward.

Thanks,

—John

On Feb 17, 2022, at 2:15 PM, John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>> 
wrote:


Thanks, Matthew. I didn’t think of searching for it under the individual 
submission name; when I read “cross-reviewed” I interpreted that as WGLC, not 
WG adoption.

It looks to me as though there was no reply to the notification message you 
reference, do you agree? (Of course there might have been people who commented 
on the BESS list, but I don’t see anything cc’d to IDR.)

It does seem to me as though, considering the unusually close association 
between this spec and an active IDR draft, it would have made sense to 
cross-WGLC it, including a specific pointer to the overlap. I mean, I 
acknowledge that might have come to nothing since there’s considerable overlap 
between the groups — but it’s not universal overlap. Anyway, it’s water under 
the bridge now.

I’ve added the IDR chairs to the cc just in case any of them want to comment.

Regards,

—John

On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:



Hi John

Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 
(ietf.org)


Regards

Matthew

From: John Scudder via Datatracker mailto:nore...@ietf.org>>
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org
 
mailto:draft-ietf-bess-srv6-servi...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, Bocci, Matthew 
(Nokia - GB) mailto:matthew.bo...@nokia.com>>
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-bess-srv6-services-11: Discuss

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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMMUd9RiSA$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/__;!!NEt6yMaO-gk!Xv1IvUswjT0bKzhaKlbofwb5-5YGQ1hNoNs2zhAoPwPpnP-yYL6GDMPLJdcbPg$



--
DISCUSS:
--

1. The shepherd writeup for this document says “It also received an RTG DIR
review and cross-reviewed with the IDR working group”. Searching in my IDR
inbox and the IDR mailing list archives, I don’t find any sign of the
cross-review — can you please point me to it?

2. One area of concern I would have hoped IDR might have looked into is, the
document makes a creative use of the MPLS Label field of the NLRI to carry the
Function part of the SID. This means the SID is effectively split across the
NLRI and the Prefix-SID attribute. What are the potential error modes if the
Prefix-SID attribute should be lost from the route, while the NLRI is retained?

(An obvious way of addressing this particular concern would be to define a new
NLRI type with the desired semantics, instead of creatively repurposing fields
within an existing NLRI type contrary to their definitions. Such an NLRI type
would, for example, presumably state in its specification that if it was
received without an accompanying Prefix-SID attribute, that would constitute an
error.)

3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
discussion turned quickly to the assertion that no, they don’t, in VPN address
families. Let’s accept that claim for the sake of conversation. It’s still the
case that sometimes (often?) routes are distributed from VPN address families
into the Global Internet table. When this is done, by default, all the path
attributes come along for the ride. Anyone who thinks this is just a
hypothetical case might want to look back to (for example) significant network
outages that were caused around a decade ago by leakage of BGP Attribute 128
(ATTR_SET, RFC 6368) into 

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

[Alvaro Retana]

Hi!

I’m wondering about the remote-only part of your message below.

The fact that the Chairs cannot make it to Vienna should not be a deterrent
to having a portion of the meeting in-person.  I don’t know what is the
mixture of people from the WG who will be there in person is, but even
assuming “some", the tools should be in place for the chairs to run the
meeting remotely — there are some Meetecho enhancements coming.

In general, we’re recommending that if both chairs can’t make it to have a
designated person in the room in case there’s a need to coordinate the
queue, etc.


My 2c.

Alvaro.

On February 18, 2022 at 10:22:56 AM, Mankamana Mishra (mankamis) (
mankamis=40cisco@dmarc.ietf.org) wrote:

All,

Please send me slot request for IETF 113. Please note BESS session would be
only remote since none of the chairs are able to travel in person this
time.





Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Ketan Talaulikar]

Hi Alvaro,

Please check inline below for a few responses.


On Fri, Feb 18, 2022 at 5:52 PM Alvaro Retana 
wrote:

> On February 18, 2022 at 12:23:03 AM, Ketan Talaulikar wrote:
>
>
> Hi!
>
>
> > > > >
> --
> > > > > DISCUSS:
> > > > >
> --
> ...
> > > > > Clearly (from looking at rfc8986), not all endpoint behaviors
> apply to
> > > > > the services defined in this document. Should a receiver accept any
> > > > > endpoint behavior? What should a receiver do if a known but
> unrelated
> > > > > behavior (End, for example) is received?
> ...
> > > > > For any specific service (IPv4 VPN Over SRv6 Core, for example, to
> pick
> > > > > one), should the behaviors used "in practice" be enforced? What if
> > > > > different behavior is advertised? Can it safely be ignored?
>
> These two are related: Should only specific behaviors (per service) be
> accepted?
>
> If yes, I need you to specify which are those behaviors and what
> happens if a different (known) one is received.
>
> If no, what does it mean for the service if an unrelated behavior is
> advertised?
>

KT> So, this would be a result of a bug (?) on the egress PE that signals a
wrong behavior. Since the receiver is not validating, the service traffic
would still arrive at the egress PE but the handling might be erroneous due
to wrong behavior. The issue still manifests on the egress PE due to its
bug. Somewhat similar to what might happen if the egress PE were to signal
a label associated with a wrong context/service as a VPN label in MPLS VPNs.


>
>
>
>
> > > > > What should the receiver do if the endpoint behavior is known and
> > > > > applicable, but the attribute length is not set correctly?
> > > >
> > > > KT> Could you clarify which attribute length you are referring to?
> > >
> > > Sorry, I meant the argument... :-(
> >
> > KT> The behavior definition may or may not specify requirements of
> argument
> > lengths - the currently defined ones do not pose any limitation and so
> the
> > draft talks about zero or non-zero. We can clarify by saying something
> on the
> > lines that for behaviors where arguments apply, the argument length's
> > consistency must be verified against the behavior definition. Would that
> > address your comment?
>
> Yes, it would.
>

KT> Thanks.


>
> Also, if the verification fails then what?
>

KT> That is already covered by the existing text in sec 8 - such a route
would be considered ineligible during the selection of the best path by the
receiver.


>
>
>
> > > > >
> --
> > > > > COMMENT:
> > > > >
> --
> > > ...
> > >
> > > Just one comment:
> > >
> > >
> > > ...
> > > > > (8) §5:
> > > > >
> > > > > The SRv6 Service SID SHOULD be routable within the AS of the egress
> > > > > PE and serves the dual purpose of providing reachability between
> > > > > ingress PE and egress PE while also encoding the SRv6 Endpoint
> > > > > behavior.
> > > > >
> > > > > Is it ever ok for the SID to not be routable? If so, when? The
> > > > > "purpose of providing reachability" requires the SID to be
> routable.
> > > > > IOW, why is this behavior recommended and not required?
> > > >
> > > > KT> An SRv6 SID may not be routable across multiple IGP domains
> within a
> > > > provider network when routes are not leaked. There can be other
> > > > mechanisms like SR Policies (or other forms of tunneling) that
> provide
> > > > reachability. In other scenarios, due to local policy, the
> resolution may
> > > > be desired over an SR Policy instead of the best-effort reachability
> > > > provided by IGPs.
> > >
> > > If there's a route over a tunnel/SR Policy/whatever, I consider that
> > > routable. I am not just thinking about IGP-learned routes. The case
> > > that concerns me is when the ingress PE doesn't have a route at all
> > > (which is possible with the SHOULD). If a route should always exist
> > > (from any source) then it looks like the text should indicate a
> > > requirement and not a recommendation.
> >
> > KT> The should is to allow for use-cases such as the one specified in
> > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-
> > policy-18#section-8.5 - in this case, there may not be any reachability
> but
> > the local policy indicates triggering a request to a controller to
> compute SR
> > Policy path to the BGP NH on demand and then the resolution can happen
> once
> > such an SR Policy is successfully instantiated on the node.
>
> The end result is that the SID MUST be reachable before the ingress
> node can do anything with it.  As you say: "the resolution can happen
> once such an SR Policy is successfully instantiated on the node".  The
> mechanisms to provide that resolution (IGP, manual configuration,
> controller, etc.) 

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

[Gyan Mishra]

Hi Mankamana

I would like to request a 10 minute time slot for both drafts below:

This draft we will be discussing name change to IPv6-Only PE design and
updates as well as changing from BCP to Standards Track as to the design
and paradigm shift for all PE-CE edge and inter-as PE-PE peering framework
which impacts IXP POPs worldwide related to IPv4 address depletion issues.

https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/

Also discuss how the draft below is an extension to the above draft and is
all inclusive of all AFI/SAFI single IPv6-Only PE design extensibility
framework and would be also Standards Track.

Also discuss the R testing and implementation being done by vendors
Cisco, Juniper, Nokia, Arista and Huawei and the additional testing being
incorporated given the “all safi” draft below.

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-all-safi-ipv6nh/



Kind Regards

Gyan

On Fri, Feb 18, 2022 at 10:22 AM Mankamana Mishra (mankamis)  wrote:

> All,
>
> Please send me slot request for IETF 113. Please note BESS session would
> be only remote since none of the chairs are able to travel in person this
> time.
>
>
>
>
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Please send me slot request for IETF 113 (BESS is only remote )

[Mankamana Mishra (mankamis)]

All,
Please send me slot request for IETF 113. Please note BESS session would be 
only remote since none of the chairs are able to travel in person this time.


Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Alvaro Retana]

On February 18, 2022 at 12:23:03 AM, Ketan Talaulikar wrote:


Hi!


> > > > --
> > > > DISCUSS:
> > > > --
...
> > > > Clearly (from looking at rfc8986), not all endpoint behaviors apply to
> > > > the services defined in this document. Should a receiver accept any
> > > > endpoint behavior? What should a receiver do if a known but unrelated
> > > > behavior (End, for example) is received?
...
> > > > For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick
> > > > one), should the behaviors used "in practice" be enforced? What if
> > > > different behavior is advertised? Can it safely be ignored?

These two are related: Should only specific behaviors (per service) be
accepted?

If yes, I need you to specify which are those behaviors and what
happens if a different (known) one is received.

If no, what does it mean for the service if an unrelated behavior is advertised?




> > > > What should the receiver do if the endpoint behavior is known and
> > > > applicable, but the attribute length is not set correctly?
> > >
> > > KT> Could you clarify which attribute length you are referring to?
> >
> > Sorry, I meant the argument... :-(
>
> KT> The behavior definition may or may not specify requirements of argument
> lengths - the currently defined ones do not pose any limitation and so the
> draft talks about zero or non-zero. We can clarify by saying something on the
> lines that for behaviors where arguments apply, the argument length's
> consistency must be verified against the behavior definition. Would that
> address your comment?

Yes, it would.

Also, if the verification fails then what?



> > > > --
> > > > COMMENT:
> > > > --
> > ...
> >
> > Just one comment:
> >
> >
> > ...
> > > > (8) §5:
> > > >
> > > > The SRv6 Service SID SHOULD be routable within the AS of the egress
> > > > PE and serves the dual purpose of providing reachability between
> > > > ingress PE and egress PE while also encoding the SRv6 Endpoint
> > > > behavior.
> > > >
> > > > Is it ever ok for the SID to not be routable? If so, when? The
> > > > "purpose of providing reachability" requires the SID to be routable.
> > > > IOW, why is this behavior recommended and not required?
> > >
> > > KT> An SRv6 SID may not be routable across multiple IGP domains within a
> > > provider network when routes are not leaked. There can be other
> > > mechanisms like SR Policies (or other forms of tunneling) that provide
> > > reachability. In other scenarios, due to local policy, the resolution may
> > > be desired over an SR Policy instead of the best-effort reachability
> > > provided by IGPs.
> >
> > If there's a route over a tunnel/SR Policy/whatever, I consider that
> > routable. I am not just thinking about IGP-learned routes. The case
> > that concerns me is when the ingress PE doesn't have a route at all
> > (which is possible with the SHOULD). If a route should always exist
> > (from any source) then it looks like the text should indicate a
> > requirement and not a recommendation.
>
> KT> The should is to allow for use-cases such as the one specified in
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-
> policy-18#section-8.5 - in this case, there may not be any reachability but
> the local policy indicates triggering a request to a controller to compute SR
> Policy path to the BGP NH on demand and then the resolution can happen once
> such an SR Policy is successfully instantiated on the node.

The end result is that the SID MUST be reachable before the ingress
node can do anything with it.  As you say: "the resolution can happen
once such an SR Policy is successfully instantiated on the node".  The
mechanisms to provide that resolution (IGP, manual configuration,
controller, etc.) is independent of the requirement for there to be
reachability.

Alvaro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess