The example is correct even under the assumption label values L1-L11 are ordered. Encoding says for subdomain label range encodings in 2.2:
It MAY appear multiple times in the BIER Sub-TLV. That aligns as well with the conceptual model I sent out ... ISIS and OSPF encodings are 100% alligned ... On Sun, Jun 18, 2017 at 6:12 PM, 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/ > <https://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-07.txt>dr > aft-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) <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 > > -- *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 OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
