Hi Acee,

Thanks for the comments.

The ordering is not by SD, but SI.

The text below this example says the following:

"The first label in the range could correspond to SI 0, and the second to SI 1."


The “key” for the Label range is {SD, BSL}, and the index into the range is SI. 
So in the example below you see a Label range of 4 labels (L1-L4) for {0,256}, 
2 labels (L5-L6) for {0,512}, etc….

Does that clarify it?

Thx,

Ice.


> On 19 Jun 2017, at 03:12, Acee Lindem (acee) <a...@cisco.com> wrote:
> 
> Hi Tony, 
> 
> I’m not saying they that BSL 256 and 512 bit strings would share any labels. 
> What I’m saying is that the OSPF encoding (didn’t look at IS-IS) doesn’t 
> allow them to share the same label range yet the example in the MPLS 
> encapsulation draft implies that they are interleaved by SD in the same label 
> range. Here is the second example:
> 
> 
>       L1:   corresponding to SD 0, BSL 256, SI 0.
> 
>       L2:   corresponding to SD 0, BSL 256, SI 1.
> 
>       L3:   corresponding to SD 0, BSL 256, SI 2.
> 
>       L4:   corresponding to SD 0, BSL 256, SI 3.
> 
>       L5:   corresponding to SD 0, BSL 512, SI 0.
> 
>       L6:   corresponding to SD 0, BSL 512, SI 1.
> 
>       L7:   corresponding to SD 1, BSL 256, SI 0.
> 
>       L8:   corresponding to SD 1, BSL 256, SI 1.
> 
>       L9:   corresponding to SD 1, BSL 256, SI 2.
> 
>       L10:  corresponding to SD 1, BSL 256, SI 3.
> 
>       L11:  corresponding to SD 1, BSL 512, SI 0.
> 
>       L12:  corresponding to SD 1, BSL 512, SI 1.
> 
> Note that they are ordered by SD – not BSL. However, that the OSPF encoding 
> is BSL specific. So, a label range would only include the SD/SI labels for a 
> single BSL. 
> 
>     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            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Lbl Range Size |                Label Range Base               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | BS Length |                    Reserved                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> I think the example should be updated to match the protocol encoding.
> 
> Thanks,
> Acee 
> 
> From: Tony Przygienda <tonysi...@gmail.com>
> Date: Sunday, June 18, 2017 at 3:17 PM
> To: Acee Lindem <a...@cisco.com>
> Cc: "gjs...@gmail.com" <gjs...@gmail.com>, "b...@ietf.org" <b...@ietf.org>, 
> OSPF WG List <ospf@ietf.org>
> Subject: Re: [Bier] WGLC: draft-ietf-bier-ospf-bier-extensions-05
> 
> Acee, can you refer to more specific section in  
> https://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-07.txt ? I don't 
> think that it is assumed that BSL 256 and 512 in the same subdomain would 
> ever share labels ...  I sent the conceptual model on the AD review for 
> -architecture that all drafts follow (as far I understood/helped writing 
> them) ... 
> 
> --- tony 
> 
> On Sun, Jun 18, 2017 at 11:40 AM, Acee Lindem (acee) <a...@cisco.com> wrote:
> Hi Greg, Authors, 
> 
> I support publication. Also, I have two comments. 
> 
>    1. It is somewhat strange to make protocol drafts standards track while 
> the architecture and encapsulations are experimental. 
>    2. The OSPF encoding will not support the second example in 
> https://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-07.txt. In this 
> example, the BSL 256 and 512 are intermixed. While with the encoding, they 
> would need to be two separate ranges of labels. 
> 
> I also have some editorial comments but I’ll just pass them to the authors.  
> 
> Thanks,
> Acee 
> 
> From: BIER <bier-boun...@ietf.org> on behalf of Greg Shepherd 
> <gjs...@gmail.com>
> Reply-To: "gjs...@gmail.com" <gjs...@gmail.com>
> Date: Wednesday, June 14, 2017 at 5:34 PM
> To: "b...@ietf.org" <b...@ietf.org>, OSPF WG List <ospf@ietf.org>
> Subject: [Bier] WGLC: draft-ietf-bier-ospf-bier-extensions-05
> 
> BIER, OSPF
> 
> At BIER WG meeting, IETF97 in Chicago, we decided to move forward to WGLC for 
> some of our docs. We learned that even once published the IESG has a process 
> to change the track of the RFC if the WG makes the case to move the work from 
> Informational to Standards track. The feedback from operators is that RFC 
> status was more important than track, and we won't be able to meet our 
> charter requirements to change track without deployment experience and 
> operator support.
> 
> This email starts a two week timer for feedback on the draft:
> https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/
> 
> WGLC to run in parallel in both BIER and OSPF WGs due to the scope of the 
> work.
> 
> Thanks,
> Greg
> (BIER Chairs)
> 
> 
> 
> _______________________________________________
> BIER mailing list
> b...@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
> 
> 
> 
> 
> -- 
> We’ve heard that a million monkeys at a million keyboards could produce the 
> complete works of Shakespeare; now, thanks to the Internet, we know that is 
> not true.
> —Robert Wilensky
> _______________________________________________
> BIER mailing list
> b...@ietf.org
> https://www.ietf.org/mailman/listinfo/bier



_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to