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 <[email protected]<mailto:[email protected]>>
Date: Sunday, June 18, 2017 at 3:17 PM
To: Acee Lindem <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, 
OSPF WG List <[email protected]<mailto:[email protected]>>
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/<https://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-07.txt>draft-ietf-bier-mpls-encapsulation-07.txt<https://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-07.txt><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) 
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on behalf of 
Greg Shepherd <[email protected]<mailto:[email protected]>>
Reply-To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, June 14, 2017 at 5:34 PM
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, OSPF WG List 
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to