Hi All,
A new version of draft-matsushima-spring-srv6-deployment-status has been posted.
The diffs include public announcement from Iliad and Cisco of the deployment of
SRv6 in Italy:
https://newsroom.cisco.com/press-release-content?type=webcontent=1978361
The deployment includes
Ole,
Inline
Ron
Juniper Internal
> -Original Message-
> From: Ole Troan
> Sent: Wednesday, May 8, 2019 3:48 PM
> To: Ron Bonica
> Cc: Bob Hinden ; Tom Herbert
> ; SPRING WG ; 6man WG
>
> Subject: Re: SRv6 Network Programming: ENH = 59
>
> Hi Ron,
>
> >
Hi Ron,
> Whatever we decide, I will use the same value in
> draft-bonica-6man-vpn-dest-opt.
Ah, right. Because in your proposal the VPN Context Information contains the
forwarding instructions?
Seems a little underspecified in the draft, or am I missing something?
And that is information
Tom,
If the authors of the network programming draft are willing to impose the
two-byte header between the SRH and the Ethernet frame, 97 works.
I will let them speak for themselves regarding there willingness to do so.
Ron
Sander,
>
> The next-header should identify what follows, so that anybody parsing the
> packets knows what to expect. Using "No Next Header" should mean "nothing
> follows". Once we start using No-next-header for "some stuff may follow" it
> will become very hard to make sense of packets.
Ole,
Whatever we decide, I will use the same value in draft-bonica-6man-vpn-dest-opt.
Ron
Juniper Internal
> -Original Message-
> From: Ole Troan
> Sent: Wednesday, May 8, 2019 3:33 PM
> To: Ron Bonica
> Cc: Bob Hinden ;
Ron,
> If you want to conserve space in the registry, you can do one of the
> following:
I don't think I said I wanted to conserve space outright.
But it is an 8-bit number space, so clearly if anyone wants more bits than
that, they cannot rely on the protocol field.
Note I'm arguing this
Bob,
The value 97 is tempting, but it already has a meaning that is slightly
different from what the authors of draft-ietf-spring-srv6-network-programming
intend. According to RFC 3378, a value of 97 means that the next header will be
as depicted in Figure 2 of RFC 3378.
Ole,
If you want to conserve space in the registry, you can do one of the following:
- Update RFC 8200, redefining value 59 to mean "VPN Payload - type unspecified"
- Update RFC 8200, redefining value 59 to mean "IP Processing Stops Here"
- Allocate a new type called "VPN Payload - type
Ole,
> On May 8, 2019, at 11:13 AM, Ole Troan wrote:
>
> Ron,
>
>>
>>
>> Folks,
>>
>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
>> define a set of SIDs that have the following things in common:
>>
>> - they are consumed by the egress node (SL == 0)
>> -
On Wed, May 8, 2019 at 11:13 AM Ole Troan wrote:
>
> Ron,
>
> >
> >
> > Folks,
> >
> > Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
> > define a set of SIDs that have the following things in common:
> >
> > - they are consumed by the egress node (SL == 0)
> > -
Hi,
> Ron,
>
>>
>>
>> Folks,
>>
>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
>> define a set of SIDs that have the following things in common:
>>
>> - they are consumed by the egress node (SL == 0)
>> - they tell the egress node how to forward the payload
Folks,
Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
define a set of SIDs that have the following things in common:
- they are consumed by the egress node (SL == 0)
- they tell the egress node how to forward the payload into a VPN
If the payload is IPv4, the
13 matches
Mail list logo
