Re: [Pce] Fwd: PCE-BSID Question to the List

2019-01-07 Thread Dhruv Dhody 
Hi Zhibo,

Thanks for the input, I like the encoding proposed by you. I will discuss this 
with my co-authors; IMHO any existing implementation would require to be change 
when code-point is allocated so a change of format of the TLV should not be a 
deal breaker for any implementation out in the field.

I think we should also update the document to include a SRv6 binding type.

Thanks!
Dhruv

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Huzhibo
Sent: 07 January 2019 17:04
To: jefftant.i...@gmail.com; pce@ietf.org
Subject: Re: [Pce] Fwd: PCE-BSID Question to the List

Hi Jeff,

I think this extension is important. Please see my reply inline.

Thanks,
Zhibo


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, November 07, 2018 10:19 AM
To: pce@ietf.org
Subject: [Pce] Fwd: PCE-BSID Question to the List

Dear PCE,

Following our presentation in Bangkok, 
https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-23-binding-segment-00.pdf

The authors would like to ask the WG the following:


(1) Do we link the Binding SID to the PCEP SR capability? Currently we
can assign BSID for RSVP-TE LSP as well.

[Zhibo]Yes, it is important, I could think of few use cases-> “domain 
stitching”,” solving MSD limits” and “interworking b/w MPLS and SRv6 domains” 
by PCE


(2) Is WG happy with TE-PATH-BINDING TLV format?

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Type (BT) | Binding Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (continued) (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Zhibo] I prefer the length of BT field is 8 bits, and adding 24 reserved bits 
for future features, such as flag or something else.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  BT   | reserved  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~Binding Value (variable length)~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This encoding of BSID is similar to BGP 
[https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2]
 that works for both SR-MPLS and SRv6.
When length is 8, then the binding Value is a MPLS label, when length is 20, 
the binding value is a SRv6 SID.


Figure 2: TE-PATH-BINDING TLV

(3) Is there a use case for binding value as “index” in SRGB/SRLB?
[Zhibo] I think there is no use case for binding value as “index” in SRLB, 
cause BSID may not be a global label.


Thanks!

Cheers,
Jeff
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Fwd: PCE-BSID Question to the List

2019-01-07 Thread Huzhibo 
Hi Jeff,

I think this extension is important. Please see my reply inline.

Thanks,
Zhibo


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, November 07, 2018 10:19 AM
To: pce@ietf.org
Subject: [Pce] Fwd: PCE-BSID Question to the List

Dear PCE,

Following our presentation in Bangkok, 
https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-23-binding-segment-00.pdf

The authors would like to ask the WG the following:


(1) Do we link the Binding SID to the PCEP SR capability? Currently we
can assign BSID for RSVP-TE LSP as well.

[Zhibo]Yes, it is important, I could think of few use cases-> “domain 
stitching”,” solving MSD limits” and “interworking b/w MPLS and SRv6 domains” 
by PCE


(2) Is WG happy with TE-PATH-BINDING TLV format?

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Type (BT) | Binding Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (continued) (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Zhibo] I prefer the length of BT field is 8 bits, and adding 24 reserved bits 
for future features, such as flag or something else.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  BT   | reserved  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~Binding Value (variable length)~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This encoding of BSID is similar to BGP 
[https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2]
 that works for both SR-MPLS and SRv6.
When length is 8, then the binding Value is a MPLS label, when length is 20, 
the binding value is a SRv6 SID.


Figure 2: TE-PATH-BINDING TLV

(3) Is there a use case for binding value as “index” in SRGB/SRLB?
[Zhibo] I think there is no use case for binding value as “index” in SRLB, 
cause BSID may not be a global label.


Thanks!

Cheers,
Jeff
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

2019-01-07 Thread Julien Meuric 
Hi Jeff,

You're right. I certainly don't want to change the specification, nor to
add another ambiguity. I was just looking for a mnemonic to mitigate the
confusion pointed out by Martin, to be considered between bracket
(leaving the definition as is).
Would "limit-blind" make sense?

Cheers,

Julien


On 06/01/2019 20:20, Jeff Tantsura wrote:
> Hi Julien,
>
> Happy New Year to you too.
> There’s a slight difference between limitless (e.g. unlimited) and
> limit has not been been imposed (not configured/unknown/etc).
> I think  “limitless” doesn’t convey the exact meaning. In simple terms
> - if L=1, don’t use MSD as a constraint in the path computation.
>
> Thanks,
> Jeff
>
> On Fri, Jan 4, 2019 at 02:28  > wrote:
>
> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term
> "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no
> limit" is *very* confusing. For me L stands for Limit and when L=1
> there is a limit, when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change :-)
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-auto-bandwidth

2019-01-07 Thread Julien Meuric 
Hi,

This LC has ended, without pointed out issue. We will then move to
shepherd review.

Thanks,

Julien


On 13/12/2018 14:29, Julien Meuric wrote:
> Hi all,
>
> This e-mail starts a 3-week PCE WG Last Call on
> draft-ietf-pce-stateful-pce-auto-bandwidth-08. Please share your reviews
> and comments using the mailing list by Friday January 5, 2019.
>
> Thank you,
>
> Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce