Subject: Last Call on BGP Labels

From: George Swallow <[email-masked]>
Date: Mon, 13 Dec 1999 11:43:40 -0500

I'd like to start a last call on 

    draft-ietf-mpls-bgp4-mpls-03.txt

The last call closes 12/23/99, 5 pm est.

...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Eric Gray <[email-masked]>
Date: Mon, 13 Dec 1999 14:42:34 -0500

Eric/Yakov,

	I have one concern with respect to this draft.

	As currently written, it is clear that an LSP
must exist between two BGP peers before they should
attempt to assign labels.  It is not clear how it is
that a BGP peer is expected to know this.

	I think that specific examples should be given
to illustrate how two BGP peers that are not directly 
connected can determine for certain that an LSP exists
between them at any given instant in time.  As you know,
this is important because - when not directly connected 
- BGP peers have to stack labels in order to tunnel them
via the intervening routers.  If any of the links in the
path between two peers are not MPLS links, this results
in dropping packets as the "tunnel" label is stripped 
off and it is discovered that additional labels are
present.

	I am not certain that it is possible to be sure
that there is a continuous LSP between two BGP peers if
the LSP is setup using hop-by-hop routed LDP.  I am also
reasonably sure that BGP peers will not always be able 
to tell if an MPLS links stops functioning when hop-by-hop 
LDP is used - forcing packets to traverse a non-MPLS link.

	One solution is to suggest that BGP peers should
establish LSPs using explicit routing (either CR-LDP or
RSVP-Tunnels) as this will result in explicit indication
of a complete LSP and explicit notification when it goes
down.

---

From: Eric Gray <[email-masked]>
Date: Mon, 13 Dec 1999 14:49:43 -0500

Eric/Yakov,

	I believe that the security section of this 
draft can and should say something about the protection
provided by BGP's use of TCP MD5 signature option (as
described in RFC2385).  Wording in [LDP] can probably 
be pared down fairly easily to provide the right text.

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Mon, 13 Dec 1999 15:45:13 -0500

It's certainly true that  if there is no LSP between the  two BGP peers, and
if they also are not on a  common subnetwork, then any attempt by one to use
the labels assigned by the other will result in lost packets. 

We  regard this  as  an operational/configuration  error  in the  network(s)
connecting  the  two BGP  peers.   The  determination  that the  network  is
correctly configured  and is properly operating  is not within  the scope of
the label distribution protocol.

---

From: Srinivasan Balaji <[email-masked]>
Date: Mon, 13 Dec 1999 17:20:49 -0500

Eric (Gray),
    I think that knowledge of LSP between BGP peers
does not necessarily have to be specified
explicitly in the documents and should be implementation
dependent. This is because there are multiple
mechanisms to do it and there are multiple ways to
figure out when the LSP goes down and also this will
be an active area of work in the near future.

  Regarding packets going through non-MPLS links,
this case is no different than any other stacking case
in the data path as the intermediate LSRs do not
know anything about the packets in tunnel irrespective
of the mechanism to setup the tunnel.

    I agree with you that it is not possible to know if
end to end LSP has been setup using LDP even if
all the LSRs use DOD ordered control as someone
might send a mapping message on finding the next
hop to be non-MPLS. Explicitly using CR-LDP or
RSVP-TE are the only choices. It may have been
useful to define a flag (with FEC/32) to indicate that
the map must come from the device having FEC/32
address as one of the addresses. (does it
boil down to CR-LDP??)

Thanks
Balaji.

--
  -----------------------------------------------------------------
  Srinivasan Balaji
  Ficon Technology
  Voice : (732) 283-2770 xtn.303
  Fax   : (732) 283-2848
  mailto:[email-masked]
  Web   : http://www.ficon-tech.com
  -----------------------------------------------------------------

---

From: Eric Rosen <[email-masked]>
Date: Wed, 15 Dec 1999 15:32:06 -0500

Balaji> I agree with you  that it is not possible to know  if end to end LSP
Balaji> has  been setup  using LDP  even  if all  the LSRs  use DOD  ordered
Balaji> control as someone might send  a mapping message on finding the next
Balaji> hop to be non-MPLS. Explicitly  using CR-LDP or RSVP-TE are the only
Balaji> choices.

Actually, these don't do what you want either:

- As Liam has pointed out, with  the use of route reflectors, in general one
  doesn't  know the  identities of  all the  other BGP  speakers  which will
  receive your label mappings. 

- There is no  reason to suppose that only one LSP  between two BGP speakers
  is  used to  carry  data traffic  from one  to  the other.   There may  be
  multiple LSPs  in use, for  various reasons (load  balancing, differential
  QoS,  etc.).  I  don't see  how you  could ensure,  before  distributing a
  label, that none of the LSPs needed to transport data packets from one BGP
  speaker to the other will be defective. 

As I've said, this is really an operations issue not a protocol issue.

Balaji> It may have  been useful to define a flag  (with FEC/32) to indicate
Balaji> that the map must come from  the device having FEC/32 address as one
Balaji> of the addresses.

Let L be a  BGP-distributed label, and let B be the  BGP next hop associated
with that label.   I think all one can  say is that when one  pushes label L
onto a packet, one  needs to have some way of getting  the packet to B, such
that when the packet reaches B, L  will reach the top of the stack.  Using a
label-switched path whose FEC  is a /32 address of B is  one way to do this,
but not necessarily the only way. 

Liam> State that  the labels  being distributed are  for use in  LSP tunnels
Liam> that must  exist between the  BGP speaker receiving the  receiving the
Liam> route and the next hop advertised for the route.

Or when the two BGP speakers are immediately adjacent.  There's no objection
to putting in some clarifying text about this.